Event and accounting logs

The log files saved in local storage can be encrypted using the AES-256-CTR cipher algorithm.

Use the following command to configure the log file encryption key and enable log file encryption. The encryption key is used for all local log files in the system.

configure log encryption-key

An event log can be configured to send events to one syslog destination. Syslog destinations have the following properties:

• Syslog server IP address

• UDP port or TLS profile used to send the Syslog message

• Syslog Facility Code (0 to 23) (default 23 - local 7)

• Syslog Severity Threshold (0 to 7); sends events exceeding the configured level

Because syslog uses eight severity levels whereas the SR OS uses six internal severity levels, the SR OS severity levels are mapped to syslog severities. The following table describes the severity level mappings.

The general format of an SR OS Syslog message is the following, as defined in RFC 3164, The BSD Syslog Protocol:

<PRI><HEADER> <MSG>

where:

• <PRI> is a number that is calculated from the message Facility and Severity codes as follows:

  Facility * 8 + Severity

  The calculated PRI value is enclosed in "<" and ">" angle brackets in the transmitted Syslog message.

• <HEADER> is composed of the following:

  <TIMESTAMP> <HOSTNAME>

  • <TIMESTAMP> immediately follows the trailing ">" from the PRI part, without a space between. Depending on the configuration of the configure log syslog timestamp-format command, the format is either:

    MMM DD HH:MM:SS

    or

    MMM DD HH:MM:SS.sss

    There are always two characters for the day (DD). Single digit days are preceded with a space character. Either UTC or local time is used, depending on the configuration of the time-format command for the event log.

  • <HOSTNAME> follows the <TIMESTAMP> with a space between. It is an IP address by default, or can be configured to use other values using the following commands:

    configure log syslog hostname
    configure service vprn log syslog hostname

• <MSG> is composed of the following:

  <log-prefix>: <seq> <vrtr-name> <application>-<severity>-<Event Name>-<Event ID> [<subject>]: <message>\n

  • <log-prefix> is an optional 32 characters of text (default = 'TMNX') as configured using the log-prefix command.

  • <seq> is the log event sequence number (always preceded by a colon and a space char)

  • <vrtr-name> is vprn1, vprn2, … | Base | management | vpls-management

  • <subject> may be empty resulting in []:

  • \n is the standard ASCII newline character (0x0A)

Examples (from different nodes)

default log-prefix (TMNX):

<188>Jan  2 18:43:23 10.221.38.108 TMNX: 17 Base SYSTEM-WARNING-tmnxStateChange-
2009 [CHASSIS]:  Status of Card 1 changed administrative state: inService, 
operational state: outOfService\n
<186>Jan  2 18:43:23 10.221.38.108 TMNX: 18 Base CHASSIS-MAJOR-tmnxEqCardRemoved-
2003 [Card 1]:  Class IO Module : removed\n

no log-prefix:

<188>Jan 11 18:48:12 10.221.38.108 : 32 Base SYSTEM-WARNING-tmnxStateChange-2009
[CHASSIS]:  Status of Card 1 changed administrative state: inService, 
operational state: outOfService\n
<186>Jan 11 18:48:12 10.221.38.108 : 33 Base CHASSIS-MAJOR-tmnxEqCardRemoved-
2003 [Card 1]:  Class IO Module : removed\n

log-prefix "test":

<186>Jan 11 18:51:22 10.221.38.108 test: 47 Base CHASSIS-MAJOR-tmnxEqCardRemoved-
2003 [Card 1]:  Class IO Module : removed\n
<188>Jan 11 18:51:22 10.221.38.108 test: 48 Base SYSTEM-WARNING-tmnxStateChange-
2009 [CHASSIS]:  Status of Card 1 changed administrative state: inService, 
operational state: outOfService\n

configure log syslog hostname
configure service vprn log hostname

Syslog messages containing log events can be optionally sent over TLS instead of UDP. TLS support for log event Syslog messages is based on RFC 5425, which provides security for syslog through the use of encryption and authentication. Use the following command to enable TLS for syslog log events by configuring a TLS profile against the syslog profile.

configure log syslog tls-client-profile

Syslog over TLS packets are sent with a fixed TCP source port of 6514.

TLS is supported for the following log event syslogs:

• system syslogs (configure log syslog), which can send Syslog messages as follows:

  • in-band (for example, out a port on an IMM)

  • out-of-band (out a CPM Ethernet port in the management router instance)

  The configure log route-preference command configuration determines where the TLS connection is established for the base system syslogs.

• service VPRN syslogs using the following command

  configure service vprn log syslog

You can configure complex rules to match log events as the trigger for EHS. For example, use the commands in the following context to configure discard using suppression and throttling:

• MD-CLI

  configure log log-events

• classic CLI

  configure log event-control

When a log event is generated in SR OS, it is subject to discard using the configured suppression and throttling before it is evaluated as a trigger for EHS, according to the following:

• EHS does not trigger on log events that are suppressed through the configuration.

• EHS does not trigger on log events that are throttled by the logger.

EHS is triggered on log events that are dropped by user-configured log filters assigned to individual logs.

Use the following command to assign log filters:

configure log filter

The EHS event trigger logic occurs before the distribution of log event streams into individual logs.

The parameters from the log event are passed into the triggered EHS CLI script or Python application. For CLI scripts, the parameters are passed as individual dynamic variables (for example, $eventid). For Python applications, see the details in the following sections. The parameters are composed of:

• common events
• event specific options

The common event parameters are:

• appid
• eventid
• severity
• gentime (in UTC)
• timestamp (in seconds, available within a Python application only)

The event specific parameters depend on the log event. Use the following command to obtain information for a particular log event.

show log event-parameters

Alternatively, in the MD-CLI use the following command for information.

state log log-events

When using the classic CLI, an EHS script has the ability to define local (static) variables and uses basic .if or .set syntax inside the script. The use of variables with .if or .set commands within an EHS script adds more logic to the EHS scripting and allows the reuse of a single EHS script for more than one trigger or action.

Both passed-in and local variables can be used within an EHS script, either as part of the CLI commands or as part of the .if or .set commands.

The following applies to both CLI commands and .if or .set commands (where X represents a variable):

• Using $X, without using single or double quotes, replaces the variable X with its string or integer value.

• Using ‟X”, with double quotes, means the actual string X.

• Using ‟$X”, with double quotes, replaces the variable X with its string or integer value.

• Using ‛X’, with single quotes does not replace the variable X with its value but means the actual string $X.

The following interpretation of single and double quotes applies:

• All characters within single quotes are interpreted as string characters.

• All characters within double quotes are interpreted as string characters except for $, which replaces the variable with its value (for example, shell expansion inside a string).

When using model-driven configuration mode and the MD-CLI, EHS can trigger a Python application that is executed inside a Python interpreter running on SR OS. See the Python chapter for more information.

Python applications are not supported in classic configuration mode or mixed configuration mode.

When developing an EHS Python application, the event attributes are passed to the application using the get_event function in the pysros.ehs module.

To import this module, the Python application developer must add the following statement to the application.

from pysros.ehs import get_event

Use the get_event function call to obtain the event triggered the Python application to run. The following example catches the event and returns a Python object into the event variable.

event = get_event()

When using an EHS Python application, the operator can use the Python programming language to create applications, as required. See the Python chapter for information about displaying model-driven state or configuration information, performing transactional configuration of SR OS, or executing CLI commands in Python.

Common event parameters (group one) are available in Python from the object created using the get_event function, as shown in the following table (the functions assume that the EHS event object is called event).

The variable parameters (group two) are available in Python in the eventparameters attribute of the event object, as shown in the following table. They are presented as a Python dictionary (unordered).

In addition to the variables, the format_msg() function is provided to output the formatted log string from the event as it would appear in the output of the show log command.

print(event.format_msg())

Launch of none operation failed with a error: Python script's operational status is not 'inService'. The script policy "test_ehs" created by the owner "TiMOS CLI" was executed with cli-user account "not-specified"

EHS debounce (also called dampening) is the ability to trigger an action (for example an EHS script), if an event happens (N) times within a specific time window (S).

N = [2..15]

S = [1..604800]

For example, when linkDown occurs N times in S seconds, an EHS script is triggered to shut down the port.

The execution of EHS or CRON scripts depends on the CLI engine associated with the configuration mode. The EHS or CRON script execution engine is based on the configured primary CLI engine. Use the following command to configure the primary CLI engine.

configure system management-interface cli cli-engine

For example, if cli-engine is configured to classic-cli, the script executes in the classic CLI infrastructure and disregards the configuration mode, even if it is model-driven.

The following is the default behavior of the EHS or CRON scripts, depending on the configuration mode:

• model-driven configuration mode

  EHS or CRON scripts execute in the MD-CLI environment and an error occurs if any classic CLI commands exist. Python applications are fully supported and use the SR OS model-driven interfaces and the pySROS libraries to obtain and manipulate state and configuration data, as well as pySROS API calls to execute MD-CLI commands.

• classic configuration mode

  EHS or CRON scripts execute in the classic CLI environment and an error occurs if any MD-CLI commands exist. Python applications are not supported and the system returns an error.

• mixed configuration mode

  EHS or CRON scripts execute in the classic CLI environment and an error occurs if any MD-CLI commands exist. Python applications are not supported and the system returns an error.

EHS or CRON scripts that contain MD-CLI commands can be used in the MD-CLI as follows:

• scripts can be configured

• scripts can be created, edited, and results read through FTP

• scripts can be triggered and executed

• scripts generate an error if there are any non MD-CLI commands or .if or .set syntax in the script

When a user is not specified, an EHS or CRON script and an EHS or CRON Python application bypasses authorization and can execute all commands.

In all configuration modes, a script policy can be disabled using the following command even if history exists:

• MD-CLI

  configure system script-control script-policy admin-state disable

• classic CLI

  configure system script-control script-policy shutdown

When the script policy is disabled, the following applies:

• Newly triggered EHS or CRON scripts or Python applications are not allowed to execute or queue.

• In-progress EHS or CRON scripts or Python applications are allowed to continue.

• Already queued EHS or CRON scripts or Python applications are allowed to execute.

By default, a script policy is configured to allow an EHS or CRON script to override datastore locks from any model-driven interface (MD-CLI, NETCONF, and so on) in mixed and model-driven modes. Use the following command to configure a script policy to prevent EHS or CRON scripts from overriding datastore locks:

• MD-CLI

  configure system script-control script-policy lock-override false

• classic CLI

  configure system script-control script-policy no lock-override

Python APIs are used to assemble a Syslog message which, in SR OS, has the format described in section Syslog.

The following table describes Python information that can be used to manipulate Syslog messages.

For example, assume that the syslog format is:

<PRI><timestamp> <hostname> <log-prefix>: <sequence> <router-name>  <appid>-
<severity>-<name>-<eventid> [<subject>]: <text>

Then the syslogPdu is constructed via Python as shown in the following example:

syslogPdu = "<" + syslog.severityToPRI(event.severity) + ">" \ + event.timestamp + "
 " \ + syslog.hostname + " " + syslog.logPrefix + ": " + \ event.sequence + " " + ev
ent.routerName + " " + \  event.application + "-
" + \ syslog.severityToName(event.severity) + "-" + \
               event.eventName + "-" + event.eventId + " [" + \
               event.subject + "]: " + event.message

Python APIs are used to modify and assemble a Syslog message which, in SR OS, has the format described in section Syslog.

The syslog module for Python 3 is included in the pySROS libraries pre-installed on the SR OS device. The get_event function must be imported from the pysros.syslog module at the beginning of each Python 3 application by including the following:

from pysros.sylog import get_event

The specific event that the syslog handler is processing can be returned in a variable using the following example Python 3 code:

my_event = get_event()

In the preceding example, my_event is an object of type Event. The Event class provides a number of parameters and functions as described in the following table:

The parameter values for the specific event are provided in the Event class. At the end of the Python application execution, the resultant values are returned to the syslog system to transmit the Syslog message. Any changes made to the read-write parameters are used in the Syslog message unless the drop() method is called.

More information about the pysros.syslog module can be found in the API documentation for pySROS delivered with the pySROS libraries.

Certain logging environments require customized formatting of the timestamp. Nokia provides a timestamp conversion method in the alu.syslog Python module to convert a timestamp from the format YYYY/MM/DD hh:mm:ss into a UNIX-based timestamp format (seconds from Jan 01 1970 – UTC).

For example, an operator can use the following Python method to convert a timestamp from the YYYY/MM/DD hh:mm:ss.ss or YYYY/MM/DD hh:mm:ss (no centiseconds) format into either the UNIX timestamp format or the MMM DD hh:mm:ss format.

from alc import event
from alc import syslog
from alc import system
#input format: YYYY/MM/DD hh:mm:ss.ss  or YYYY/MM/DD hh:mm:ss
#output format 1: MMM DD hh:mm:ss
#output format 2: unixTimestamp (TBD)
def timeFormatConversion(timestamp,format):
    if format not in range(1,2):
        raise NameError('Unexpected format, expected:' \
                        '0<format<3 got: '+str(format))
    try:
        dat,tim=timestamp.split(' ')
    except:
        raise NameError('Unexpected timestamp format, expected:' \
                        'YYYY/MM/DD hh:mm:ss got: '+timestamp)
    try:
        YYYY,MM,DD=dat.split('/')
    except:
        raise NameError('Unexpected timestamp format, expected:' \
                        'YYYY/MM/DD hh:mm:ss got: '+timestamp)
    try:
        hh,mm,ss=tim.split(':')
        ss=ss.split('.')[0]   #just in case that the time format is hh:mm:ss.ss
    except:
        raise NameError('Unexpected timestamp format, expected:' \
                        'YYYY/MM/DD hh:mm:ss got: '+timestamp)
    if not (1970<=int(YYYY)<2100 and 
            1<=int(MM)<=12 and 
            1<=int(DD)<=31 and 
            0<=int(hh)<=24 and 
            0<=int(mm)<=60 and 
            0<=int(ss)<=60):
        raise NameError('Unexpected timestamp format, or values out of the range' \
                        'Expected: YYYY/MM/DD hh:mm:ss got: '+timestamp)
    if format == 1:
        MMM={1:'Jan',
             2:'Feb',
             3:'Mar',
             4:'Apr',
             5:'May',
             6:'Jun',
             7:'Jul',
             8:'Aug',
             9:'Sep',
             10:'Oct',
             11:'Nov',
             12:'Dec'}[int(MM)]
        timestamp=MMM+' '+DD+' '+hh+':'+mm+':'+ss
    if format == 2:
        timestamp=syslog.timestampToUnix(timestamp)       
    return timestamp

The timeFormatConversion method can accept the event.timestamp value in the format:

YYYY/MM/DD HH:MM:SS.SS 

and return a new timestamp in the format determined by the format parameter:

1  MMM DD HH:MM:SS
2  Unix based time format

This method accepts the input format in either of the two forms, YYYY/MM/DD HH:MM:SS.SS or YYYY/MM/DD HH:MM:SS, and ignores the centisecond part in the former form.

Certain logging environments require customized formatting of the timestamp. The Python 3 interpreter provided with SR OS also provides the utime and datetime modules for format manipulation.

Users can define a collection of fields that make up a record. These records can be assigned to an accounting policy. These are user-defined records instead of being limited to pre-defined record types. The operator can select queues and policers and the counters within these queues and policers that need to be collected. See the predefined records containing a specific field for XML field name of a custom record field.

A record is only generated if a significant change has occurred to the fields being written in a specific record. This capability applies to both ingress and egress records regardless on the method of delivery (such as RADIUS and XML). The capability also applies to Application Assurance records; however without an ability to specify different significant change values and per-field scope (for example, all fields of a custom record are collected if any activity was reported against any of the statistics that are part of the custom record).

Another way to decrease accounting messaging related to overhead is to include only ‟active” objects in a periodical reporting. An ‟active object” in this context is an object which has seen a ‟significant” change in corresponding counters. A significant change is defined in terms of a cumulative value (the sum of all reference counters).

This concept is applicable to all methods used for gathering accounting information, such as an XML file and RADIUS, as well as to all applications using accounting, such as service-acct, ESM-acct, and Application Assurance.

Accounting records are reported at the periodical intervals. This periodic reporting is extended with an internal filter which omits periodical updates for objects whose counter change experienced lower changes than a defined (configurable) threshold.

Specific to RADIUS accounting the significant-change command does not affect ACCT-STOP messages. ACCT-STOP messages are always sent, regardless the amount of change of the corresponding host.

For Application Assurance records, a significant change of 1 in any field of a customized record (send a record if any field changed) is supported. When configured, if any statistic field records activity, an accounting record containing all fields is collected.

For ESM RADIUS accounting, an accounting stop message is sent when:

• A subscriber/subscriber-host is deleted.

• An SLA profile instance is changed.

A similar concept is also used for XML accounting. In case the accounted object is deleted or changed, the latest information is written in the XML file with a ‟final” tag indication in the record header. This functionality applies to the 7750 SR only.

A log file policy contains information used to direct events, alarms, traps, and debug information to a file on a local storage device (for example, cf2:). One or more event sources can be specified. File policies, SNMP trap groups, or syslog policies must be configured before they can be applied to an event log.

Use commands in the following context to configure an event log file.

configure log log-id

The following example shows an event log file configuration.

[ex:/configure log]
A:admin@node-2# info
    log-id "2" {
        description "This is a test log file."
        filter "1"
        source {
            main true
            security true
        }
        destination {
            file "1"
        }
    }

A:node-2>config>log>log-id$ info
----------------------------------------------
...
log-id 2 name "2"
    description "This is a test log file."
    filter 1
    from main security
    to file 1
exit
...
----------------------------------------------

To create a log file, a file policy is defined, the target CF or USB drive is specified, and the rollover and retention interval for the log file is defined. The rollover interval is defined in minutes and determines how long a file is used before it is closed and a new log file is created. The retention interval determines how long the file is stored on the storage device before it is deleted.

When creating new log files in a compact flash disk card, the minimum amount of free space is the minimum of 10% of Compact Flash disk capacity or 5 Mb (5,242,880 = 5 × 1024 × 1024).

The following example shows a log file configuration.

[ex:/configure log]
A:admin@node-2# info
    file "1" {
        description "This is a log file."
        rollover 600
        retention 24
        compact-flash-location {
            primary cf1
        }
    } 

A:node-2>config>log# info
------------------------------------------
        file-id 1 name "1"
            description "This is a log file."
            location cf1:
            rollover 600 retention 24
        exit
----------------------------------------------

A log file policy must be created to collect the accounting records. The files are stored in system memory of compact flash (cf1: or cf2:) in a compressed (tar) XML format and can be retrieved using FTP or SCP. See Configuring an event log and Configuring a log file policy.

Accounting policies must be configured in the configure log context before they can be applied to a service SAP or service interface, or applied to a network port.

The default accounting policy statement cannot be applied to LDP nor RSVP statistics collection records.

An accounting policy must define a record type and collection interval. Only one record type can be configured per accounting policy.

When creating accounting policies, one service accounting policy and one network accounting policy can be defined as default. If statistics collection is enabled on a SAP or network port and no accounting policy is applied, then the respective default policy is used. If no default policy is defined, then no statistics are collected unless a specifically defined accounting policy is applied.

By default, the subscriber host volume accounting data is based on the 14-byte Ethernet DLC header, 4-byte or 8-byte VLAN Tag (optional), 20-byte IP header, IP payload, and the 4-byte CRC (everything except the preamble and inter-frame gap). See Subscriber host volume accounting data. This default can be altered by the packet-byte-offset configuration option.

The following example shows an accounting policy configuration.

[ex:/configure log]
A:admin@node-2# info
    accounting-policy 4 {
        description "This is the default accounting policy."
        default true
        record complete-service-ingress-egress
        destination {
            file "1"
        }
    }
    accounting-policy 5 {
        description "This is a test accounting policy."
        record service-ingress-packets
        destination {
            file "3"
        }
    } 

A:node-2>config>log# info
----------------------------------------------
accounting-policy 4
    description "This is the default accounting policy."
    record complete-service-ingress-egress
    default
    to file 1
exit
accounting-policy 5
    description "This is a test accounting policy."
    record service-ingress-packets
    to file 3
exit
---------------------------------------------- 

The following example shows a custom-record configuration.

ex:/configure log accounting-policy 1]
A:admin@node-2# info
    custom-record {
        significant-change 20
        queue 1 {
            e-counters {
                in-profile-octets-discarded-count true
                in-profile-octets-forwarded-count true
                out-profile-octets-discarded-count true
                out-profile-octets-forwarded-count true
            }
            i-counters {
                high-octets-discarded-count true
                in-profile-octets-forwarded-count true
                low-octets-discarded-count true
                out-profile-octets-forwarded-count true
            }
        }
        ref-queue {
            all
            e-counters {
                in-profile-packets-forwarded-count true
                out-profile-packets-forwarded-count true
            }
            i-counters {
                in-profile-packets-forwarded-count true
                out-profile-packets-forwarded-count true
            }
        }
    }

[ex:/configure log accounting-policy 1]
A:admin@node-2# info
    custom-record {
        significant-change 1
        aa-specific {
            aa-sub-counters {
                long-duration-flow-count true
                medium-duration-flow-count true
                short-duration-flow-count true
                total-flow-duration true
                total-flows-completed-count true
            }
            from-aa-sub-counters {
                flows-active-count true
                flows-admitted-count true
                flows-denied-count true
                forwarding-class true
                max-throughput-octet-count true
                max-throughput-packet-count true
                max-throughput-timestamp true
                octets-admitted-count true
                octets-denied-count true
                packets-admitted-count true
                packets-denied-count true
            }
            to-aa-sub-counters {
                flows-active-count true
                flows-admitted-count true
                flows-denied-count true
                forwarding-class true
                max-throughput-octet-count true
                max-throughput-packet-count true
                max-throughput-timestamp true
                octets-admitted-count true
                octets-denied-count true
                packets-admitted-count true
                packets-denied-count true
            }
        }
        ref-aa-specific-counter {
            any true
        }
    }

A:node-2>config>log>acct-plcy# info
----------------------------------------------
...
            custom-record
                queue 1
                    i-counters
                        high-octets-discarded-count
                        low-octets-discarded-count
                        in-profile-octets-forwarded-count
                        out-profile-octets-forwarded-count
                    exit
                    e-counters
                        in-profile-octets-forwarded-count
                        in-profile-octets-discarded-count
                        out-profile-octets-forwarded-count
                        out-profile-octets-discarded-count
                    exit
                exit
                significant-change 20
                ref-queue all
                    i-counters
                        in-profile-packets-forwarded-count
                        out-profile-packets-forwarded-count
                    exit
                    e-counters
                        in-profile-packets-forwarded-count
                        out-profile-packets-forwarded-count
                    exit
                exit
...
---------------------------------------------- 

A:node-2>config>log>acct-policy# info
----------------------------------------------
...
                custom-record         
                    aa-specific
                        aa-sub-counters
                            short-duration-flow-count
                            medium-duration-flow-count
                            long-duration-flow-count
                            total-flow-duration
                            total-flows-completed-count
                        exit
                        from-aa-sub-counters
                            flows-admitted-count
                            flows-denied-count
                            flows-active-count
                            packets-admitted-count
                            octets-admitted-count
                            packets-denied-count
                            octets-denied-count
                            max-throughput-octet-count
                            max-throughput-packet-count
                            max-throughput-timestamp
                            forwarding-class
                        exit
                        to-aa-sub-counters
                            flows-admitted-count
                            flows-denied-count
                            flows-active-count
                            packets-admitted-count
                            octets-admitted-count
                            packets-denied-count
                            octets-denied-count
                            max-throughput-octet-count
                            max-throughput-packet-count
                            max-throughput-timestamp
                            forwarding-class
                        exit
                    exit
                    significant-change 1
                    ref-aa-specific-counter any
...
-------------------------------------------------- 

The following example shows an event control configuration.

[ex:/configure log]
A:admin@node-2# info
    log-events {
        ospf event tmnxOspfVirtIfStateChange {
            generate false
            throttle false
        }
        ospf event tmnxOspfVirtNbrStateChange {
            severity cleared
            throttle false
        }
        ospf event tmnxOspfLsdbOverflow {
            severity critical
            throttle false
        }
    }
    throttle-rate {
        limit 500
        interval 10
    }

A:node-2>config>log# info
#------------------------------------------
echo "Log Configuration"
#------------------------------------------
        throttle-rate 500 interval 10
        event-control "oam" 2001 generate throttle
        event-control "ospf" 2001 suppress
        event-control "ospf" 2003 generate cleared
        event-control "ospf" 2014 generate critical
...
----------------------------------------------

configure log filter

The following example shows a log filter configuration.

[ex:/configure log]
A:admin@node-2# info
    file "1" {
        description "This is our log file."
        rollover 600
        retention 24
        compact-flash-location {
            primary cf1
        }
    }
    filter "1" {
        description "This is a sample filter."
        default-action drop
        named-entry "1" {
            action forward
            match {
                application {
                    eq mirror
                }
                severity {
                    eq critical
                }
            }
        }
    }
    log-id "2" {
        admin-state disable
        description "This is a test log file."
        filter "1"
        source {
            main true
            security true
        }
        destination {
            file "1"
        }
    }

A:node-2>config>log# info
#------------------------------------------
echo "Log Configuration "
#------------------------------------------
        file-id 1 name "1"
            description "This is our log file."
            location cf1:
            rollover 600 retention 24
        exit
        filter 1 name "1"
            default-action drop
            description "This is a sample filter."
            entry 1
                action forward
                match
                    application eq "mirror"
                    severity eq critical
                exit
            exit
        exit
...
        log-id 2 name "2"
            shutdown
            description "This is a test log file."
            filter 1
            from main security
            to file 1
        exit
...
------------------------------------------

The associated log ID does not have to be configured before an SNMP trap group can be created; however, the SNMP trap group must exist before the log ID can be configured to use it.

[ex:/configure log]
A:admin@node-2# info
    log-id "2" {
        description "This is a test log file."
        filter "1"
        source {
            main true
            security true
        }
        destination {
            snmp {
            }
        }
    }

[ex:/configure log]
A:admin@node-2# info
    snmp-trap-group "2" {
        trap-target "ops-mon-4" {
            address 10.10.10.104
            version snmpv2c
            notify-community "warnings-12a7"
        }
    }

A:node-2>config>log# info
----------------------------------------------
...
snmp-trap-group 2
    trap-target "ops-mon-4" address 10.10.10.104 snmpv2c notify-community "warnings-12a7" 
exit
...
log-id 2
    description "This is a test log file."
    filter 1
    from main security
    to snmp
exit
...
----------------------------------------------

A:node-2>config>log# snmp-trap-group 2
A:node-2>config>log>snmp-trap-group# info
----------------------------------------------
      trap-target "xyz-test" address xx.xx.x.x snmpv2c notify-community "xyztesting"
      trap-target "test2" address xx.xx.xx.x snmpv2c notify-community "xyztesting"
----------------------------------------------
*A:node-2>config>log>log-id# info
----------------------------------------------
      from main
      to snmp
----------------------------------------------
*A:node-2>config>router# interface xyz-test
*A:node-2>config>router>if# info
----------------------------------------------
      address xx.xx.xx.x/24
      port 1/1/1
----------------------------------------------

A valid syslog ID must exist to send log events to a syslog target host.

The following example shows a syslog configuration.

[ex:/configure log]
A:admin@node-2# info
    syslog "1" {
        description "This is a syslog file."
        address 10.10.10.104
        facility user
        severity warning
    }

A:node-2>config>log# info
----------------------------------------------
...
        syslog 1 name "1"
            description "This is a syslog file."
            address 10.10.10.104
            facility user
            level warning
        exit
...
----------------------------------------------

A log file configuration can be modified.

[ex:/configure log]
A:admin@node-2# info
    log-id "2" {
        description "This is a test log file."
        filter "1"
        source {
            main true
            security true
        }
        destination {
            file "1"
        }
    }

[ex:/configure]
A:admin@node-2# log log-id 2

[ex:/configure log log-id "2"]
A:admin@node-2# description "Chassis log file"

[ex:/configure log log-id "2"]
A:admin@node-2# filter 2

[ex:/configure log log-id "2"]
A:admin@node-2# destination file 2

[ex:/configure log log-id "2"]
A:admin@node-2#

*[ex:/configure log]
A:admin@node-2# info
    log-id "2" {
        description "Chassis log file."
        filter "2"
        source {
            security true
        }
        destination {
            file "1"
        }
    }

A:node-2>config>log>log-id# info
----------------------------------------------
...
log-id 2 name "2"
            description "This is a test log file."
            filter 1
            from main security
            to file 1
exit
...
----------------------------------------------

*A:node-2>config# log
*A:node-2>config>log# log-id 2
*A:node-2>config>log>log-id# description "Chassis log file."
*A:node-2>config>log>log-id# filter 2
*A:node-2>config>log>log-id# from security
*A:node-2>config>log>log-id# exit

A:node-2>config>log# info
----------------------------------------------
...
log-id 2 name "2"
            description "Chassis log file."
            filter 2
            from security
            to file 1
exit
...
----------------------------------------------

Use the following command to delete a log file:

• MD-CLI

  It is not necessary to disable the log ID before you delete it. Also, you can use the delete command in any context.

  delete

• classic CLI

  You must shutdown the log ID before you delete it.

  configure log log-id shutdown
  configure log no log-id 2

The following example shows how to delete a log file.

[ex:/configure log log-id "2"]
A:admin@node-2# info
    description "filter "1001"
    destination {
        file "50"
    }

*[ex:/configure log]
A:admin@node-2# delete log-id 2

A:node-2>config>log# info
----------------------------------------------
file-id name "1"
            description "LocationTest."
            location cf1:
            rollover 600 retention 24
        exit
...
log-id name "2"
            description "Chassis log file."
            filter 2
            from security
            to file 1
exit
...
*A:node-2>config>log# log-id 2
*A:node-2>config>log>log-id# shutdown
*A:node-2>config>log>log-id# exit
*A:node-2>config>log# no log-id 2

You can modify the syslog ID for a log. All references to the syslog ID must be deleted before the syslog ID can be removed.

[pr:/configure log]
A:admin@Dut-G# syslog 1

*[pr:/configure log syslog "1"]
A:admin@Dut-G# description "Test syslog"

*[pr:/configure log syslog "1"]
A:admin@Dut-G# address 10.10.0.91

*[pr:/configure log syslog "1"]
A:admin@Dut-G# facility mail

*[pr:/configure log syslog "1"]
A:admin@Dut-G# severity info

*[pr:/configure log syslog "1"]

[ex:/configure log syslog]
A:admin@node-2# info
...
    syslog "1" {
        description "Test syslog"
        address 10.10.0.91
        facility mail 
        severity info
        }
    }

*A:node-2>config# log
*A:node-2>config>log# syslog 1
*A:node-2>config>log>syslog$ description "Test syslog."
*A:node-2>config>log>syslog# address 10.10.0.91
*A:node-2>config>log>syslog# facility mail
*A:node-2>config>log>syslog# level info

A:node-2>config>log# info
----------------------------------------------
...
        syslog 1 name "1"
            description "Test syslog."
            address 10.10.10.91
            facility mail
            level info
        exit
...
----------------------------------------------

Use the following commands to delete SNMP trap groups:

• MD-CLI

  configure log snmp-trap-group delete trap-target
  configure log delete snmp-trap-group 

• classic CLI

  configure log snmp-trap-group no trap-target
  configure log no snmp-trap-group

A:node-2>config>log# info
----------------------------------------------
...
       snmp-trap-group name "10"
           trap-target "ops-mon-4" address 10.10.10.104 snmpv2c notify-community "warnings-12a7"
       exit
...
----------------------------------------------

*A:node-2>config>log# snmp-trap-group 
*A:node-2>config>log>snmp-trap-group# no trap-target ops-mon-4
*A:node-2>config>log>snmp-trap-group# exit
*A:node-2>config>log# no snmp-trap-group 10

You can modify the configuration of a log filter.

[ex:/configure log]
A:admin@node-2# info
...
    filter "1" {
        description "This is a sample filter with default action drop."
        default-action drop
        }
    }
...  

*[ex:/configure]
A:admin@node-2# log filter 1

*[ex:/configure log filter "1"]
A:admin@node-2# description "This filter allows forwarding"

*[ex:/configure log filter "1"]
A:admin@node-2# default-action forward

A:node-2>config>log>filter# info
----------------------------------------
...
        filter name "1"
            description "This filter allows forwarding"
             default-action forward
            exit
        exit
...
----------------------------------------

A:node-2>config>log# info
#------------------------------------------
echo "Log Configuration "
#------------------------------------------
...
        filter name "1"
            default-action drop
            description "This is a sample filter."
            entry 1
                action forward
                match
                    application eq "mirror"
                    severity eq critical
                exit
            exit
        exit
...
------------------------------------------

A:node-2>config# log
*A:node-2>config>log# filter 1
*A:node-2>config>log>filter# description "This allows <n>."
*A:node-2>config>log>filter# default-action forward
*A:node-2>config>log>filter# entry 1
*A:node-2>config>log>filter>entry$ action drop
*A:node-2>config>log>filter>entry# match 
*A:node-2>config>log>filter>entry>match# application eq user
*A:node-2>config>log>filter>entry>match# number eq 2001
*A:node-2>config>log>filter>entry>match# no severity
*A:node-2>config>log>filter>entry>match# exit

A:node-2>config>log>filter# info
----------------------------------------
...
        filter name "1"
            description "This allows <n>."
            entry 1
                action drop
                match
                    application eq "user"
                    number eq 2001
                exit
            exit
        exit
...
----------------------------------------

Use the following command to delete modified log event options and return them to the default values:

• MD-CLI

  configure log log-events delete event option

• classic CLI

  configure log no event-control application [event-name | event-number]

The following example shows the command usage.

[ex:/configure log log-events]
A:admin@node-2# delete snmp event authenticationFailure

A:node-2>config>log# no event-control "bgp" 2001