| Home Prev |  cOS Core 15.00.01 Administration Guide
|
Next |
|---|
The ability to log and analyze system activities is an essential feature of cOS Core. Logging enables not only monitoring of system status and health, but also allows auditing of network usage and assists in troubleshooting.
Log Message Generation
cOS Core defines a large number of different log messages, which are generated as a result of corresponding system events. Examples of such events are the establishment and tear-down of connections, receipt of malformed packets as well as the dropping of traffic according to filtering policies.Log events are always generated for some aspects of cOS Core processing such as buffer usage, DHCP clients, High Availability and IPsec. The generation of events for some cOS Core subsystems, such as IP rule set usage, can be disabled or enabled as required.
Whenever an event message is generated, it can be filtered and distributed to a variety of Event Receivers, including Syslog and SNMP Trap receivers. Up to eight event receivers can be defined per firewall, with each receiver having its own customizable event filter.
Log Message Analysis Using InCenter
The InCenter Cloud service is a separate cloud based Clavister product that can be used to analyze log event messages from one or multiple cOS Core firewalls. The firewalls are configured to send log messages to the Clavister cloud and then a web browser can be used by the administrator to connect to the cloud and perform analysis on the stored messages and also to generate reports in PDF format. Reports can be generated on demand or automatically sent at specified intervals by email.More information about the InCenter Cloud service can be found in the separate InCenter Cloud Administration Guide and companion InCenter Cloud Getting Started Guide. To begin using the InCenter cloud, request a subscription to the product by selecting the option after logging into the relevant MyClavister account.
The InCenter product is also available as an "on-premises" option so that the administrator can run the software on their own private server and the log messages from firewalls can be sent to this server instead of the cloud. This product is further described in the separate InCenter On-Premises Administration Guide. To obtain a license for this software, contact a Clavister sales office.
InCenter will not be discussed further in this section.
The conn_open event, for example, is a typical high-level event that generates an event message whenever a new connection is established, given that the matching security policy rule has defined that event messages should be generated for that connection.
An example of a low-level event would be the startup_normal event, which generates a mandatory event message as soon as the system starts up.
Message Format
All event messages have a common format, with attributes that include category, severity and recommended actions. These attributes enable easy filtering of messages, either within cOS Core prior to sending to an event receiver, or as part of the analysis after logging and storing messages on an external log server.A list of all event messages can be found in the separate cOS Core Log Message Reference Guide. The beginning of that publication describes the design of log messages, and the various parameters that can appear in them.
The default severity of each log event is predefined and it can be, in order of highest to lowest severity, one of:
By default, cOS Core sends any generated messages of level Info and above to any configured log servers but the level required for sending can be changed by the administrator. The Debug severity is intended for system troubleshooting only and is not normally used. All individual log messages with their meaning are described in the separate cOS Core Log Reference Guide.
When log messages are generated by cOS Core for sending to an external log server, they are always time stamped with the time expressed as UTC/GMT (Greenwich Mean Time). This makes it possible to compare events from different firewalls in different time zones which are set with different system times.The exception to this is log messages which are displayed using the local Memlog feature. These are always time stamped with the current, local system time.
The event messages generated by cOS Core can be sent to one or more log receivers. For cOS Core to send log messages, it is necessary to configure in cOS Core one or more such log receiver objects. Each log receiver object is configured with properties that specify which events to capture and where to send them (for example, an Syslog external server).
cOS Core can distribute event messages to different types of receivers and these are enabled by creating any of the following types of Log Receiver objects.
Memory Log Receiver
cOS Core has its own logging mechanism also known as the MemLog. This retains all event log messages in memory and allows direct viewing of recent log messages through the Web Interface.
This is enabled by default but can be disabled.
This receiver type is discussed further below in Section 2.3.4, The Memory Log Receiver (memlog).
Syslog Receiver
Syslog is the de-facto log message standard for logging events from network devices. If other network devices are already logging to Syslog servers, using Syslog for cOS Core log messages can simplify overall administration.
This receiver type is discussed further below in Section 2.3.5, The Syslog Log Receiver.
Mail Alerting
The Mail Alerting function allows a number of log messages to be grouped together into a single email which is then sent to a given email address via a designated SMTP server.
This receiver type is discussed further below in Section 2.3.7, Mail Alerting.
InControl Log Receiver
The separate Clavister InControl management product has the ability to receive and analyze log messages for one or many Clavister firewalls. Event messages sent to the InControl log receiver use the Clavister proprietary event message format for logging called FWLog. This format has a high level of detail and is suitable for allowing analysis of large amounts of log data.
This receiver type is discussed further below in Section 2.3.8, The InControl Log Receiver (FWLog).
SNMP Traps
An SNMP2c Event Receiver can be defined to collect SNMP Trap log messages. These receivers are typically used to collect and respond to critical alerts from network devices.
This receiver type is discussed further below in Section 2.3.10, SNMP Traps.
Overview
The Memory Log Receiver (also known as memlog) is a feature in cOS Core that allows logging direct to firewall memory in real-time instead of sending messages to an external server. These messages can be examined through the standard user interfaces.Viewing and Saving the Memlog Contents in the Web Interface
The entire memlog buffer can be viewed in the Web Interface by going to Status > Logging > System Log. This display is updated in real-time and it is also possible to save a snapshot of the current buffer contents to a text file by pressing the Download Logs button. It is also possible to have log messages displayed on a CLI console in real-time as they are added to memlog by using the logsnoop CLI command. This command can also be used to extract logs from the memlog buffer based on filtering criteria which are not available when using the Web Interface. The command is discussed further in Section 2.3.6, Logsnoop and all its options documented in the separate cOS Core CLI Reference Guide.InControl can also be used to view the memlog buffer and this is described further in the separate InControl Administrator Guide.
Memlog memory available for new log messages for each monitored category is limited to a fixed predetermined size. As a guide, approximately 500 log messages can be accommodated for each monitored category (for example, System or IDP). However, this number can vary according to th size of the log messages being stored.When the allocated memory is filled up with log messages, the oldest messages are discarded to make room for newer incoming messages. This means that when cOS Core is creating large numbers of messages in systems with, for example, large numbers of VPN tunnels, the memlog information becomes less meaningful since it reflects a limited recent time period.
All memlog buffers are emptied by a restart of cOS Core but a reconfiguration operation will leave them unaffected.
The timestamp shown in memlog console output is always the local system time of the firewall. This is different from the timestamp on log messages sent to external log Receivers which are always time stamped with GMT time. A single Memory Log Receiver object exists by default in cOS Core and memlog is therefore enabled by default. If logging to memlog is not required then the Memory Log Receiver object can be deleted and this type of logging will not occur. To re-enable memlog, add back the Memory Log Receiver object to the configuration. Only one instance of the Memory Log Receiver can exist at any one time.Further memlog Discussion
An article in the Clavister Knowledge Base also discusses the cOS Core memlog feature. It can be found at the following link:Overview
Syslog is a common format for sending log data and is well suited to automated processing, filtering and searching. Most Syslog receivers expect each log entry to be prefaced with a timestamp and the IP address of the machine that sent the log data. For example:Feb 5 2000 09:45:23 firewall.example.comThis is followed by the text the sender has chosen to send.
Feb 5 2000 09:45:23 firewall.example.com EFW: DROP:Subsequent text is dependent on the event that has occurred.
In order to facilitate automated processing of all messages, cOS Core writes all log data to a single line of text. All data following the initial text is presented in the format name=value. This enables automatic filters to easily find the values they are looking for without assuming that a specific piece of data is in a specific location in the log entry.
![[Note]](images/note.png) |
Note: The Prio and Severity fields |
|---|---|
|
The Prio= field in SysLog messages contains the same information as the Severity field for Clavister Logger messages. However, the ordering of the numbering is reversed. |
Example 2.28. Enable Logging to a Syslog Host
This example enables logging of all events with a severity equal to Emergency or Alert to a Syslog server with the IPv4 address 192.168.6.1.
The facility name will also be set to local1 for this Syslog server.
Command-Line Interface
Device:/> add LogReceiver LogReceiverSyslog my_syslog
IPAddress=192.168.6.1
LogSeverity=Emergency,Alert
Facility=local1InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
|
Note: The Syslog server itself must be correctly configured |
|---|---|
|
The external Syslog server itself may have to be configured to correctly receive log messages from cOS Core. Refer to the documentation for the specific Syslog server being used in order to do this. |
The InCenter product is discussed further in the separate InCenter Administration Guide and InCenter Cloud Administration Guide.
In the header of every Syslog message there is a string field which is the Syslog hostname. By default, cOS Core always sets this to be the IP address of the sending interface.If RFC-5424 compliance is enabled, it is also possible to set the hostname to a specific value. The example below shows how this is done.
Example 2.29. Enabling Syslog RFC-5424 Compliance with Hostname
This example enables logging of all events with a severity greater equal to Emergency or Alert to a Syslog server with the IPv4 address 192.168.5.1. RFC-5424 compliance will also be enabled with a hostname of my_host1 in the Syslog header.
Command-Line Interface
Device:/> add LogReceiver LogReceiverSyslog my_syslog
IPAddress=192.168.5.1
RFC5424=Yes
Hostname=my_host1
LogSeverity=Emergency,AlertInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
As described in Section 2.3.4, The Memory Log Receiver (memlog), there is a basic ability to monitor and view the log messages stored in the system memlog buffer through the Web Interface or InControl. The logsnoop CLI command extends this ability so that log messages generated by cOS Core can be viewed in any of the following ways:
Logsnoop can display log messages on the CLI console as they are generated in real-time and apply filtering to show only messages of interest to the administrator.
Logsnoop can look back in time and display the contents of the Memlog buffer which will contain a given number of the most recently generated log messages. Filtering can also be applied to this output to show only the messages of interest to the administrator.
The above two features can be combined so that both the contents of the memlog buffer and newly generated messages are displayed together.
Switching Real-time Logsnooping On and Off
To switch on snooping, the basic form of the command is:Device:/> logsnoop -onLOG: 2014-01-13 13:53:39 SYSTEM prio=Alert id=03200021 rev=1 event=demo_mode action=shutdown_soon shutdown=halt time=7200The current status of logsnooping can be examined by entering the command with no parameters:
Device:/> logsnoop
Real time log snooping is enabled. Filter: AllDevice:/> logsnoop -offFiltering Log Messages
Simply switching on snooping on a busy system can send an overwhelming number of messages to the console. It is usually advisable to add extra command parameters, either singly or in combinations, to filter the messages. The following examples illustrate using some of the many filtering parameters.Filter by severity:
Device:/> logsnoop -on -severity=warningNote that it is only possible to filter on a single severity level at once.
Filter by log ID number:
Device:/> logsnoop -on -logid=1500001All the ID numbers can be found in the separate cOS Core Log Reference Guide. Leading zeros do not need to be specified.
Filter by Source IP:
Device:/> logsnoop -on -srcip=192.168.1.10Here, the srcip field must exist in a log message for it to be displayed. For example, if the log message comes from an IP rule set entry the srcip field of a displayed message will contain the source IP for the connection that triggered the rule.
Filter by Source Interface:
Device:/> logsnoop -on -srcif=If1Here, the srcif field must exist in a log message for it to be displayed. For example, if the log message comes from an IP rule set entry, the srcif field of a displayed message will contain the source interface for the connection that triggered the rule.
Filter by combining parameters:
Device:/> logsnoop -on -severity=warning -srcip=192.168.1.10 -srcif=If1Any number of filtering parameters can be used together in a single logsnoop command.
A complete list of command parameters can be found in the entry of logsnoop in the separate cOS Core CLI Reference Guide. Alternatively, the following the CLI command can be used:
Device:/> help logsnoop
Stopping logsnoop is also discussed in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324736057
Filtering Wildcards and Free-text Filtering
When specifying filtering parameters, the following wildcards can be used:* - An asterisk represents none or many characters.
? - A question mark represents any single character.
For example, to find the text warning followed somewhere by udp, the command would be:
Device:/> logsnoop -on -pattern=*warning*udp*The -pattern parameter specifies a free-text text filter for log messages. Wildcarding can also be used with other filtering parameters and is not limited to -pattern.
Limiting Log Message Numbers
Even when using filtering, the number of messages appearing at the console may still need to be reduced. The number of messages displayed can be limited in two ways:For example, the entire contents of the memlog buffer can be examined using the command:
Device:/> logsnoop -on -source=memlogEven though the -on parameter must be used, this command does not switch on real-time logging and a matching command with the -off parameter is therefore not needed later.
Examining Memlog Plus New Log Messages
It is possible to examine the log history in memlog as well as switch on real-time log snooping at the same time. This is done with the command:Device:/> logsnoop -on -source=bothIf -source=both is used, a second command with the -off parameter will be needed later to switch off real-time logging.
The displayed log messages can be limited to those generated after a certain time with the parameter -starttime and/or those generated before a certain time with the -endtime parameter.The time value itself can be specified in the following formats:
Using Date and Time
The date and time together takes the format "yyyy-mm-dd hh.mm.ss" where the surrounding quotes are mandatory. For example: 2014-01-12 18:30:00. To look at log messages from 18:30 on the 12th of January onwards, the command would be:
Device:/> logsnoop -on -starttime="2014-01-12 18:30:00"Note that the parameter value must be enclosed by quotes when both date and time are entered.
Using Date Only
The date may be specified without the time and this takes the format yyyy-mm-dd, this time without enclosing quotes. For example: 2014-01-12. The time always defaults to 00:00:00 so this example is equivalent to 2014-01-12 00:00:00. To look at log messages for the whole of the 12th of January, the command would be:
Device:/> logsnoop -on -starttime=2014-01-12 -endtime=2014-01-13
When not looking at memlog, setting the times will act as a way of turning logsnoop on and off at specified future times. If the -source=memlog option is used, the start and end times are used to look at a specific period in the memlog history.
Overview
By creating a Mail Altering object, cOS Core can be configured to send log messages in an email to a specified email address via a nominated external SMTP server. The Mail Altering object can be considered to be like other types of log receivers and it is possible to select the type of log messages that are sent.The intended purpose of this feature is to provide a means of quickly alerting the administrator of any important cOS Core events so the selected level of severity for the events sent in this way will usually be very high.
Mail Alerting Object Properties
Many Mail Alerting object properties are the same as in other types of log receiver object and will not be listed again in this section. The object properties that are unique are the following:SMTP Server
The IP address of an SMTP server that will forward generated emails to the destination email address. This can also be an FQDN address object or a DNS resolvable FQDN (note that both require that a DNS server is configured in cOS Core).
Server Port
The port number that the SMTP server listens on. This is set by default to the standard port number of 25.
SMTP Recipient
A single destination email address for outgoing mails.
SMTP Sender
A string which will be the sender name text in emails.
Subject
A string which will be the subject text in emails.
Send Test Email
This is not a property but a button in the Web Interface used to test the SMTP properties entered. It has a CLI equivalent and is explained further later in this section.
Event Trigger Mode
Single event trigger
A single email is sent for at least each eligible event. The Event count threshold and Event count period values are not used with this option. However, when a single event is ready for sending it must wait for the Keep collecting before sending period so other eligible events can be added to the mail.
Rate of events trigger
Multiple events are collected together into each email sent. The number of events collected before email sending is controlled by the values of the Event count threshold and Event count period properties.
Event count threshold
An email is only sent if this number of events has occurred over the preceding number of minutes specified by the Event count period property. The trigger is therefore a given rate of events and not just an accumulation of events. Events that have already been included in a sent email are not counted again.
When a Mail Alerting object is first created, this count is zero and is always reset to zero when cOS Core restarts. When an email is sent by the Mail Alerting, object, this count is also reset to zero.
This property and the property Event count period are not used if Single event trigger is selected.
Event count period
This is the number of minutes referred to in the Event count threshold description above and is the period of recent time in which events are being counted.
Send report emails
When enabled, an email is always sent at least in the period of time specified by the Report email interval, even if the sent email has no events in it and even if the email is has no events in it or even if (in the case of the Rate of events trigger) the Event count threshold value has not been reached.
This is not used in Single event trigger mode
Report email interval
This is the maximum length of time in hours that can elapse before an email is sent even though the email might contain no events. Typically, this value might be set to 24 so that the Mail Alerting object generates at least one email a day even though it might be empty. This can inform the administrator that the system is up and highlight any events of interest.
Report email subject
When a report email is sent, this will be the subject line of the email. This allows the administrator to easily distinguish if an email is a report email or an email generated by a trigger.
The property must have a string value and cannot be left empty.
Keep collecting before sending
If an email is ready to be sent, cOS Core will wait this number of minutes before sending it. Any new events that occur while the email is waiting to be sent are added to the pending email.
This can be used in either triggering mode. If the mode is Single event trigger, any new events during the period after the initial triggering event will be added to the email.
cOS Core only sends events in one minute intervals so this means that even is this property is set to zero, there can still be a delay before the email is sent and extra events can still be added during this delay.
Minimum time between emails
Consecutive sent emails cannot have less than this amount of elapsed time between them. The value of this property can prevent emails being sent too often.
If an email is ready to send but cannot because it is within this period of time, any new events will be added to the email until this period has expired.
Advanced Options
Identity
This string parameter identifies the SMTP client in the HELO or EHLO command sent to the SMTP server by cOS Core. If this property is not set, cOS Core will set this automatically to the IPv4 address of the cOS Core interface that sends to the SMTP server.
X-Mailer
This is the name of the software that is communicating with the SMTP server. This is optional and is left blank by default.
Mail Alerting Processing Flow
To better explain the settings for the event trigger properties, consider the following example: a Mail Alerting object has been configured in cOS Core and the Multiple events trigger option has been selected with an Event count period value of 2 minutes and an Event count threshold value of 3 events (in other words 3 events must occur in a 2 minute window for an email to be sent).Assume that since sending its last email, 6 log events occur that are eligible for mailing and these occur over a 6 minute period of time. The diagram below divides the 6 minutes into 2 minute sections for clarity and shows when the events occur.
The processing flow is as follows:
cOS Core starts counting the events from zero before the 1st event.
The 3rd event occurs, reaching the threshold. However, the 1st event is outside the 2 minute time window and only the 2nd and 3rd events are inside the time period so an email is not sent.
This is also the case for the 4th and 5th events. There are not enough other events in the previous 2 minutes for either to reach the threshold of 3.
Only when the 6th event occurs is the threshold of 3 events reached within the previous 2 minutes and an email is sent (after waiting the Keep collecting before sending number of minutes during which time any new log events will be added to the email).
cOS Core drops the 1st, 2nd and 3rd events so these are not included in the email.
The event counter is reset to zero and event counting within the Event count period begins again.
Device:/> smtp -sendmail -logreceiver=<mail-alerting-object-name>This is message #1 sent to test the Mail Alerting object "my_mail_alert"
The number "#1" in the message will increment every time a test mail is sent from
this log receiver.
In the Web Interface, the test button can be pushed even while the Mail Alerting object is being created and before the configuration change is activated and saved. This is not true with the equivalent CLI test mail function.
Sending to Multiple Email Addresses
More than one Mail Alerting object can be created so that log messages are sent to multiple email addresses. However, if the same log message information is being sent to multiple email addresses then it is not recommended to create multiple Mail Alerting objects for this purpose. Instead, create a mailing list email address on the SMTP server so that a mail sent to that address is sent to multiple email recipients.Mail Size Limit
In order to limit the available memory that cOS Core uses for buffering log messages and building the email body, a limit is set on the email size. This limit is 8 Kbytes. When this limit is reached but the email had not yet been sent, any new log messages will be dropped. If events are dropped, the following message added to the email body:message(s) have been discarded because of because of email body size limitIf the available memory is completely used up while building the email, this message will have a slightly different text to indicate that. If messages are dropped repeatedly, it is an indication that either the event filter should be made more restrictive or that the emails should be sent more often.
If more than one Mail Alerting object is created, each will have its own piece of memory allocated for building emails.
Example 2.30. Setting up a Mail Alerting Object
This example configures an Mail Alerting object called my_smtp_receiver so that all events with a severity equal to Emergency or Alert are sent out in an email.
It is assumed that the recipient email address is admn@example.com and that the SMTP server address is 203.0.113.10. The default values for the threshold and associated properties are used.
All other configurable properties will be left at their default value.
Command-Line Interface
Device:/> add LogReceiver MailAlerting my_mail_alert
IPAddress=203.0.113.10
Receiver=admn@example.com
Sender=device1
Subject="Log message summary"
LogSeverity=Emergency,AlertInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
The Clavister Logger refers to the proprietary Clavister logging method that uses the proprietary FWLog message format for sending log data. A receiving server for this format is also sometimes referred to as a FWLog Receiver. The ILA server component of the separate Clavister InControl™ management product is such a logger and this is the primary usage of the FWlog format.
Configuring the log receiver can be done in InControl or it could be done through the Web Interface or CLI.
Example 2.31. Enabling Logging to the Clavister Logger
This example enables logging of all events to a InControl ILA server with a severity equal to Alert or Emergency to the Clavister Logger (FWLog Receiver) with IPv4 address 192.168.4.1 listening on port 999 (the default).
This same procedure could also be performed through InControl.
Command-Line Interface
Device:/> add LogReceiver LogReceiverFWLog my_fwlog
IPAddress=192.168.4.1
Port=999
LogSeverity=Emergency,AlertInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
For each log receiver it is possible to impose rules on what log message categories and severities are sent to that receiver. It is also possible to lower or raise the severity of specific events.
The Severity Filter
The Severity Filter is a means of specifying what severities, if any, are sent to the receiver. By default, all log messages except Debug are sent. This can be restricted further so, for example, only Emergency, Alert and Critical messages are sent.Log Message Exceptions
After the severity filter is applied, any Log Message Exceptions are applied to generated messages. There can be more than one message exception for a log receiver and each consists of the following:Category and ID
This specifies the log messages that will be affected by the exception. If the ID number of the log message is not specified then all log messages for the specified category will be included.
The ID of specific log messages can be found in the Log Reference Guide.
Type
This can be one the following:
Exclude - This will exclude the specified log message(s) even if they are allowed by the severity filter.
Include - This will include the specified log message(s) even if they are excluded by the severity filter.
In addition, the Severity of the included message(s) can be specified. If this is set to Default the original severity is used. Otherwise, the severity is set to the specified value. This provides the ability to raise (or lower) the severity of specific log messages.
The SNMP protocol
Simple Network Management Protocol (SNMP) is a means for communicating between a Network Management System (NMS) and a managed device. SNMP defines 3 types of messages: a Read command for an NMS to examine a managed device, a Write command to alter the state of a managed device and a Trap which is used by managed devices to send messages asynchronously to an NMS about a change of state.SNMP Traps in cOS Core
cOS Core takes the concept of an SNMP Trap one step further by allowing any event message to be sent as an SNMP trap. This means that the administrator can set up SNMP Trap notification of events that are considered significant in the operation of a network.The file CLAVISTER-TRAP.mib defines the SNMP objects and data types that are used to describe an SNMP Trap received from cOS Core.
This file is contained within cOS Core itself and can be extracted to a management computer's local disk either using the Web Interface or Secure Copy (SCP). Doing this is described further in Section 2.5, SNMP.
There is one generic trap object called OSGenericTrap, that is used for all traps. This object includes the following parameters:
This information can be cross-referenced to the separate Log Reference Guide using the ID.
cOS Core supports the sending of SNMP traps using either SNMP2c or SNMPv3. These SNMP protocol versions are very similar except that SNMPv3 can provide encryption and/or authentication and is therefore the preferred version from a security standpoint.Configuring Event Receivers
The SNMP trap feature is configured by defining either an SNMP2c Event Receiver or an SNMPv3 Event Receiver object. Both the SNMP2c and SNMPv3 log receiver objects have a property called Repeat Count which specifies how many times any single event will be sent to the receiver. The default value for this is zero which means that every time a particular event occurs, a message will be sent to the receiver.If, for example, the Repeat Count property is set to 3 then a particular event will be sent only for the first three times that it occurs since the last system startup (a system restart will initialize the count). This can prevent a constantly repeating event sending an unnecessary quantity of the same message to the receiver.
Both the SNMP2c and SNMPv3 log receiver objects have a property called Use interface link up/down traps which can be disabled or enabled and is disabled by default. If enabled, any change in the online or offline status of any Ethernet interface in the configuration will cause an event to be sent to the receiver. When using SNMPv3, there are three levels of security that can be chosen:noAuthNoPriv - This disables both authentication and encryption (the default).
authNoPriv - This enables authentication using SHA-1 but disables encryption. Authentication is performed using the Password property which must be specified.
authPriv - This enables authentication using SHA-1 and enables encryption using AES. Authentication and encryption are performed using the Password property which must be specified.
Note that cOS Core performs both authentication and encryption using the same password. cOS Core does not support a separate password for each operation.
Example 2.32. Configuring an SNMPv3 Event Receiver
This example configures an SNMPv3 Event Receiver receiver in cOS Core that will receive SNMP traps for all events with a severity of Emergency or Alert
Both authentication and encryption will be enabled and the receiver is assumed to have an IPv4 address of 192.168.3.1.
Command-Line Interface
Device:/> add LogReceiver EventReceiverSNMPv3 my_snmp_receiver
IPAddress=192.168.3.1
Username=my_name
Password=myunguessablepassword
Snmp3SecurityLevel=authPriv
LogSeverity=Emergency,AlertInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
The following advanced settings for cOS Core event logging are available to the administrator:
This setting specifies the maximum log messages that cOS Core will send per second. This value should never be set too low as this may result in important events not being logged. When the maximum is exceeded, the excess messages are dropped and are not buffered.The administrator must make a case by case judgment about the message load that log servers can deal with. This can often depend on the server hardware platform being used and if the resources of the platform are being shared with other tasks.
The Send Limit setting is global but affects each log receiver individually.
|
Note: The send limit is not shared between log receivers |
|---|---|
|
If multiple log receivers are configured, the send limit is calculated for each log receiver before any log events are sent to the log receivers. As an example: If two log receivers are configured and the limit is 2000, it means that 2000 log messages can be sent to each log receiver. |
If the send limit is reached, a log message about throttling will be generated describing how many log messages that were lost. Example:
03200400;;Warning;SYSTEM;log_messages_lost_due_to_throttling;
249 messages lost due to throttling
Default: 2000
The delay in seconds between alarms when a continuous alarm is used. This setting is not available in virtual environments. As discussed in Section 2.4.4, Hardware Monitoring, the log messages generated by hardware monitoring are continuous and this setting should be used to limit the frequency of those messages.Minimum 0, Maximum 10,000.
Default: 60 (one minute)
