7.1.1. Logging Using the Management VPRN

When a management VPRN is configured, all authentication, authorization, and accounting servers, DNS server, or syslog servers are reachable using this management VPRN. The user can configure a syslog server within the management VPRN, log all SR OS events, and direct the logs to this syslog server. The command config>log>services-all-events service id enables the logging of all events under the management VPRN specified by the service ID. Within the specified VPRN, the command config>service>vprn>log>log-id>from directs the logs from the specified event sources (main, change, security, or debug-trace) to be saved at the log ID destination specified by the config>service>vprn>log>log-id>to command.

7.2.1. Console

Sending events to a console destination means the message will be sent to the system console The console device can be used as an event log destination.

7.2.2. Session

A session destination is a temporary log destination which directs entries to the active telnet or SSH session for the duration of the session. When the session is terminated, for example, when the user logs out, the “to session” configuration is removed. Event logs configured with a session destination are stored in the configuration file but the “to session” part is not stored. Event logs can direct log entries to the session destination.

7.2.3. CLI Logs

A CLI log is a log that outputs log events to a CLI session. An operator can subscribe to a CLI log from within a CLI session using the tools perform log subscribe-to log-id command. The events are sent to the CLI session for the duration of that CLI session (or until an unsubscribe-from command is issued).

7.2.4. Memory Logs

A memory log is a circular buffer. When the log is full, the oldest entry in the log is replaced with the new entry. When a memory log is created, the specific number of entries it can hold can be specified, otherwise it will assume a default size. An event log can send entries to a memory log destination.

7.2.5. Log Files

Log files can be used by both event logs and accounting logs and are stored on the compact flash devices in the file system. I

A log file is identified with a single log file ID, but a log file will generally be composed of a number individual files in the file system. A log file is configured with a rollover parameter, expressed in minutes, which represents the length of time an individual log file should be written to before a new file is created for the relevant log file ID. The rollover time is checked only when an update to the log is performed. Thus, complying to this rule is subject to the incoming rate of the data being logged. For example, if the rate is very low, the actual rollover time may be longer than the configured value.

The retention time for a log file specifies the amount of time the file should be retained on the system based on the creation date and time of the file.

When a log file is created, only the compact flash device for the log file is specified. Log files are created in specific subdirectories with standardized names depending on the type of information stored in the log file.

Event log files are always created in the \log directory on the specified compact flash device. The naming convention for event log files is:

log eeff-timestamp

where:

ee is the event log ID

ff is the log file destination ID

timestamp is the timestamp when the file is created in the form of yyyymmdd-hhmmss where:

yyyy is the four-digit year (for example, 2007)

mm is the two digit number representing the month (for example, 12 for December)

dd is the two digit number representing the day of the month (for example, 03 for the 3rd of the month)

hh is the two digit hour in a 24-hour clock (for example, 04 for 4 a.m.)

mm is the two digit minute (for example, 30 for 30 minutes past the hour)

ss is the two digit second (for example, 14 for 14)

Accounting log files are created in the \act-collect directory on a compact flash device (specifically cf1 or cf2). The naming convention for accounting log files is nearly the same as for log files except the prefix act is used instead of the prefix log. The naming convention for accounting logs is:

act aaff-timestamp.xml.gz

where:

aa is the accounting policy ID

ff is the log file destination ID

timestamp is the timestamp when the file is created in the form of yyyymmdd-hhmmss where:

yyyy is the four-digit year (for example, 2007)

mm is the two digit number representing the month (for example, 12 for December)

dd is the two digit number representing the day of the month (for example, 03 for the 3rd of the month)

hh is the two digit hour in a 24-hour clock (for example, 04 for 4 a.m.)

mm is the two digit minute (for example, 30 for 30 minutes past the hour)

ss is the two digit second (for example, 14 for 14 seconds)

Accounting logs are .xml files created in a compressed format and have a .gz extension.

The \act-collect directory is where active accounting logs are written. When an accounting log is rolled over, the active file is closed and archived in the \act directory before a new active accounting log file created in \act-collect.

When creating a new log file on a Compact Flash disk card, the system will check the amount of free disk space and that amount must be greater than or equal to the lesser of 5.2 MB or 10% of the Compact Flash disk capacity.

7.2.6. SNMP Trap Group

An event log can be configured to send events to SNMP trap receivers by specifying an SNMP trap group destination.

An SNMP trap group can have multiple trap targets. Each trap target can have different operational parameters.

A trap destination has the following properties:

For SNMP traps that will be sent out-of-band through the Management Ethernet port on the SF/CPM, the source IP address of the trap is the IP interface address defined on the Management Ethernet port. For SNMP traps that will be sent in-band, the source IP address of the trap is the system IP address of the router.

Each trap target destination of a trap group receives the identical sequence of events as defined by the log ID and the associated sources and log filter applied.

7.2.7. Syslog

7.2.7.1. Syslog Implementation Overview

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

1. Syslog server IP address
2. UDP port or TLS profile used to send the syslog message
3. Syslog Facility Code (0 to 23) (default 23 - local 7)
4. Syslog Severity Threshold (0 to 7); sends events exceeding the configured level

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

Table 35:  Router to Syslog Severity Level Mappings  

SR OS Event Severity	Syslog Severity Numerical Code	Syslog Severity Name	Syslog Severity Definition
—	0	emergency	System is unusable
critical (3)	1	alert	Action must be taken immediately
major (4)	2	critical	Critical conditions
minor (5)	3	error	Error conditions
warning (6)	4	warning	Warning conditions
—	5	notice	Normal but significant condition
cleared (1) indeterminate (2)	6	info	Informational messages
—	7	debug	Debug-level messages

The general format of an SR OS syslog message is as follows (see RFC 3164, The BSD Syslog Protocol):

<PRI> <HEADER><MSG>

Note: The “<” and “>” are informational delimiters to make reading and understanding the format easier and they do not appear in the actual syslog message except as part of the PRI.

where:

1. <PRI> (the “<” and “>” are included in the syslog message) is the configured facility*8+severity (as described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide and RFC 3164).
2. <HEADER> is "MMM DD HH:MM:SS <source IP addr>" (without the quotes). There are always 2 characters for the day (DD). Single digit days are preceded with a space character.
3. <MSG> is <log-prefix>: <seq> <vrtr-name> <application>-<severity>-<Event Name>-<Event ID> [<subject>]: <message>\n

1. <log-prefix> is an optional 32 characters of text (default = 'TMNX') as configured in the log-prefix command.
2. <seq> is the log event sequence number (always preceded by a colon and a space char)
3. <vrtr-name> is vprn1, vprn2, … | Base | management | vpls-management
4. <subject> may be empty resulting in []:
5. \n is the standard ASCII new line character (hex 0A)

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

7.2.8. NETCONF

A NETCONF log is a log that outputs log events to a NETCONF session as notifications. A NETCONF client can subscribe to a NETCONF log using the configured netconf-stream stream-name for the log in a subscription request. See NETCONF Notifications for more details.

7.3.1. Event Sources

In Figure 16, the event sources are the main categories of events that feed the log manager.

Examples of applications within the system include IP, MPLS, OSPF, CLI, services, and so on. The following example displays a partial sample of the show log applications command output which displays all applications.

7.3.2. Event Control

Event control pre-processes the events generated by applications before the event is passed into the main event stream. Event control assigns a severity to application events and can either forward the event to the main event source or suppress the event. Suppressed events are counted in event control, but these events will not generate log entries as it never reaches the log manager.

Simple event throttling is another method of event control and is configured similarly to the generation and suppression options. See Simple Logger Event Throttling.

Events are assigned a default severity level in the system, but the application event severities can be changed by the user.

Application events contain an event number and description that explains why the event is generated. The event number is unique within an application, but the number can be duplicated in other applications.

The following example, generated by querying event control for application generated events, displays a partial list of event numbers and names.

7.3.3. Log Manager and Event Logs

Events that are forwarded by event control are sent to the log manager. The log manager manages the event logs in the system and the relationships between the log sources, event logs and log destinations, and log filter policies.

An event log has the following properties:

7.3.4. Event Filter Policies

The log manager uses event filter policies to allow fine control over which events are forwarded or dropped based on various criteria. Like other filter policies in the SR OS, filter policies have a default action. The default actions are either:

Filter policies also include a number of filter policy entries that are identified with an entry ID and define specific match criteria and a forward or drop action for the match criteria.

Each entry contains a combination of matching criteria that define the application, message, event number, router, severity, and subject conditions. The entry’s action determines how the packets should be treated if they have met the match criteria.

Entries are evaluated in order from the lowest to the highest entry ID. The first matching event is subject to the forward or drop action for that entry.

Valid operators are displayed in Table 36:

A match criteria entry can include combinations of:

7.3.5. Event Log Entries

Log entries that are forwarded to a destination are formatted in a way appropriate for the specific destination whether it be recorded to a file or sent as an SNMP trap, but log event entries have common elements or properties. All application generated events have the following properties:

The general format for an event in an event log with either a memory, console or file destination is as follows.

The following is an event log example:

The specific elements that compose the general format are described in Table 37.

7.3.6. Simple Logger Event Throttling

Simple event throttling provides a mechanism to protect event receivers from being overloaded when a scenario causes many events to be generated in a very short period of time. A throttling rate, # events/# seconds, can be configured. Specific event types can be configured to be throttled. Once the throttling event limit is exceeded in a throttling interval, any further events of that type cause the dropped events counter to be incremented. Dropped events counts are displayed by the show>log>event-control context. Events are dropped before being sent to one of the logger event collector tasks. There is no record of the details of the dropped events and therefore no way to retrieve event history data lost by this throttling method.

A particular event type can be generated by multiple managed objects within the system. At the point this throttling method is applied the logger application has no information about the managed object that generated the event and cannot distinguish between events generated by object “A” from events generated by object “B”. If the events have the same event-id, they are throttled regardless of the managed object that generated them. It also does not know which events may eventually be logged to destination log-id <n> from events that will be logged to destination log-id <m>.

Throttle rate applies commonly to all event types. It is not configurable for a specific event-type.

A timer task checks for events dropped by throttling when the throttle interval expires. If any events have been dropped, a TIMETRA-SYSTEM-MIB::tmnxTrapDropped notification is sent.

7.3.7. Default System Log

Log 99 is a pre-configured memory-based log which logs events from the main event source (not security, debug, and so on). Log 99 exists by default.

The following example displays the log 99 configuration.

7.3.8. Event Handling System

The Event Handling System (EHS) is a framework that allows operator-defined behavior to be configured on the router. EHS adds user-controlled programmatic exception handling by allowing the execution of either a CLI script or a Python 3 application when a log event (the “trigger”) is detected. Various fields in the log event provide regexp style expression matching, which allows flexibility for the trigger definition.

EHS handler objects are used to tie together the following:

EHS, along with CRON, may execute SR OS CLI scripts or Python 3 applications to perform operator-defined functions as a result of receiving a trigger event. The Python programming language provides an extensive framework for automation activities for triggered or scheduled events, including model-driven transactional configuration and state manipulation. See the Python chapter for more information.

The use of Python applications from EHS is supported only in model-driven configuration mode.

Figure 17 shows the relationships among the different configurable objects used by EHS (and CRON).

Figure 17:  EHS Object Relationships 

7.3.8.1. EHS Configuration and Variables

Complex rules can be configured to match log events as the trigger for EHS.

When a log event is generated in SR OS, it is subject to discard using suppression and throttling (config>log>event-control) before it is evaluated as a trigger for EHS, according to the following.

1. EHS does not trigger on log events that are suppressed through config>log>event-control.
2. 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 (config>log>filter). The EHS event trigger logic occurs before the distribution of log event streams into individual logs.

Varbinds are variable bindings that represent the variable number of values included in a log event.

The common parameters and varbinds for a triggering log event are passed into the triggered EHS CLI script or Python application and can be used within that script or application as passed-in (dynamic) variables. Passed-in (dynamic) variables are split into the following groups:

1. Group one
   Common event parameters, as follows:
   1. appid — name of the application that generated the event
   2. eventid — event ID of the application
   3. severity — severity level of the event
   4. subject — subject or affected object of the event
   5. gentime — formatted time the even was generated (in UTC)
   6. timestamp — timestamp when the event was generated, in seconds (available within a Python application only)
2. Group two
   Variable parameters (varbinds), depending on the event. These are provided in different ways, depending on whether a CLI script or a Python application is triggered.

Note: See the show command in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Clear, Monitor, Show, and Tools Command Reference Guide for more information about showing event parameters. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Log Events Guide for the predefined varbinds for any event The event sequence number is not passed into the script.

7.3.8.2. Triggering a CLI Script from EHS

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).

1. Using $X, without using single or double quotes, replaces the variable X with its string or integer value.
2. Using “X”, with double quotes, means the actual string X.
3. Using “$X”, with double quotes, replaces the variable X with its string or integer value.
4. 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.

1. All characters within single quotes are interpreted as string characters.
2. 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).

7.3.8.2.1. Examples of EHS Syntax Supported in Classic CLI

This section describes the supported EHS syntax for the classic CLI.

Note: These scenarios use pseudo syntax.

1. .if $string_variable==string_value_or_string_variable {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
2. .if ($string_variable==string_value_or_string_variable) {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
3. .if $integer_variable==integer_value_or_integer_variable {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
4. .if ($integer_variable==integer_value_or_integer_variable) {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
5. .if $string_variable!=string_value_or_string_variable {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
6. .if ($string_variable!=string_value_or_string_variable) {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
7. .if $integer_variable!=integer_value_or_integer_variable {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
8. .if ($integer_variable!=integer_value_or_integer_variable) {
             CLI_commands_set1
   .} else {
             CLI_commands_set2
   .} endif
9. .set $string_variable = string_value_or_string_variable
10. .set ($string_variable = string_value_or_string_variable)
11. .set $integer_variable = integer_value_or_integer_variable
12. .set ($integer_variable = integer_value_or_integer_variable)

where:

1. CLI_commands_set1 is a set of one or more CLI commands
2. CLI_commands_set2 is a set of one or more CLI commands
3. string_variable is a local (static) string variable
4. string_value_or_string_variable is a string value/variable
5. integer_variable is a local (static) integer variable
6. integer_value_or_integer_variable is an integer value/variable

Note: A limit of 100 local (static) variables per EHS script is imposed. Exceeding this limit may result in an error and partial execution of the script. When a set statement is used to set a string_variable to a string_value, the string_value can be any non-integer value not surrounded by single or double quotes or it can be surrounded by single or double quotes. A "." preceding a directive (for example, if, set, and so on) is always expected to start a new line. An end of line is always expected after {. A CLI command is always expected to start a new line. Passed-in (dynamic) variables are always read-only inside an EHS script and cannot be overwritten using a set statement. .if commands support == and != operators only. .if and .set commands support addition, subtraction, multiplication, and division of integers. .if and .set commands support addition, which means concatenation, of strings.

7.3.8.2.2. Valid Examples of EHS Syntax in Classic CLI

This section provides a list of valid examples to trigger log events using EHS syntax in classic CLI.

1. configure service epipe $serviceID
   where $serviceID is either a local (static) integer variable or passed-in (dynamic) integer variable
2. echo srcAddr is $srcAddr
   where $srcAddr is a passed-in (dynamic) string variable
3. .set $ipAddr = "10.0.0.1"
   where $ipAddr is a local (static) string variable
4. .set $ipAddr = $srcAddr
   where $srcAddr is a passed-in (dynamic) string variable
              $ipAddr is a local (static) string variable.
5. .set ($customerID = 50)
   where $customerID is a local (static) integer variable
6. .set ($totalPackets = $numIngrPackets + $numEgrPackets)
   where $totalPackets, $numIngrPackets, $numEgrPackets are local (static) integer variables
7. .set ($portDescription = $portName + $portLocation)
   where $portDescription, $portName, $portLocation are local (static) string variables
8. if ($srcAddr == "CONSOLE") {
             CLI_commands_set1
   .else {
             CLI_commands_set2
   .} endif
   where $srcAddr is a passed-in (dynamic) string variable
              CLI_commands_set1 is a set of one or more CLI commands
              CLI_commands_set2 is a set of one or more CLI commands
9. .if ($customerId == 10) {
             CLI_commands_set1
   .else {
             CLI_commands_set2
   .} endif
   where $customerID is a passed-in (dynamic) integer variable            CLI_commands_set1 is a set of one or more CLI commands
              CLI_commands_set2 is a set of one or more CLI commands
10. .if ($numIngrPackets == $numEgrPackets) {
              CLI_commands_set1
    .else {
              CLI_commands_set2
    .} endif
    where $numIngrPackets and $numEgrPackets are local (static) integer variables
               CLI_commands_set1 is a set of one or more CLI commands
               CLI_commands_set2 is a set of one or more CLI commands

7.3.8.2.3. Invalid Examples for EHS Syntax in Classic CLI

This section provides a list of invalid variable use in EHS syntax in classic CLI.

1. .set $srcAddr = "10.0.0.1"
   where $srcAddr is a passed-in (dynamic) string variable
   Reason: passed-in variables are read only inside an EHS script.
2. .set ($ipAddr = $numIngrPackets + $numEgrPackets)
   where $ipAddr is a local (static) string variable  
             $numIngrPackets and $numEgrPackets are local (static) integer variables
   Reason: variable types do not match, cannot assign a string to an integer.
3. .set ($numIngrPackets = $ipAddr + $numEgrPackets)
   where $ipAddr is a local (static) string variable
               $numIngrPackets and $numEgrPackets are local (static) integer variables
   Reason: variable types do not match, cannot concatenate a string to an integer.
4. .set $ipAddr = "10.0.0.1"100
   where $ipAddr is a local (static) string variable
   Reason: when double quotes are used, they have to surround the entire string.
5. .if ($totalPackets == "10.1.1.1") {
   .} endif
   where $totalPackets is a local (static) integer variables
   Reason: cannot compare an integer variable to a string value.
6. .if ($ipAddr == 10) {
   .} endif
   where $ipAddr is a local (static) string variable
   Reason: cannot compare a string variable to an integer value.
7. .if ($totalPackets == $ipAddr) {
   where $totalPackets is a local (static) integer variables
              $ipAddr is a local (static) string variable
   Reason: cannot compare an integer variable to a string variable.

7.3.8.4. EHS Debounce

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]

Note: Triggering occurs with the Nth event not at the end of S. There is no sliding window (for example a trigger at Nth event, N+1 event, and so on), as N is reset after a trigger and count is restarted. When EHS debouncing or dampening is used, the varbinds passed in to an EHS script at script triggering time are from the Nth event occurrence (the Nth triggering event). If S is not specified then the SR OS will continue to trigger every Nth event.

For example:

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

7.4.1. Python Engine for Syslog

This section discusses syslog-specific aspects of Python processing. Refer to the “Python Script Support for ESM” section of the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide for an introduction to Python.

When an event is dispatched to the log manager in SR OS, the log manager asynchronously passes the event context data and varbinds to the Python engine, that is, the logger task is not waiting for feedback from Python. Varbinds are variable bindings that represent the variable number of values that are included in the event. Each varbind consists of a triplet (OID, type, value). Along with other system-level variables, the Python engine constructs a syslog message and sends it to the syslog destination. During this process, the operator can modify the format of the syslog message or leave it intact, as if it was generated by the syslog process within the log manager.

The tasks of the Python engine in a syslog context are as follows:

7.4.2. Python Processing Efficiency

Python retrieves event-related variables from the log manager, as opposed to retrieving pre-assembled syslog messages. This eliminates the need for string parsing of the syslog message to manipulate it constituent parts increasing the speed of Python processing.

To further improve processing performance, Nokia recommends performing string manipulation via the Python native string method, when possible.

7.4.3. Python Backpressure

A Python task assembles syslog messages based on the context information received from the logger and sends them to the syslog server independent of the logger. If the Python task is congested due to a high volume of received data, the backpressure should be sent to the ISA so that the ISA stops allocating NAT resources. This behavior matches the current behavior in which NAT resources allocation is blocked if that logger is congested.

7.4.4. Event Selection for Python Processing

Events destined for Python processing are configured through a log ID that references a Python policy. The selection of the events are performed via a filter associated with this log ID. The remainder of the events destined to the same syslog server can bypass Python processing by redirecting them to a different log ID. The following example clarifies this point:

In the example above, the configuration-only event 2012 from application "nat" will be sent to log-id 33. All other events are forwarded to the same syslog destination via log-id 34, without any modification. As a result, all events (modified via log-id 33 and unmodified via log-id 34) are sent to the syslog 1 destination.

This configuration may cause reordering of syslog messages at the syslog 1 destination due to slight delay of messages processed by Python.

7.5.1. Accounting Records

An accounting policy must define a record name and collection interval. Only one record name can be configured per accounting policy. Also, a record name can only be used in one accounting policy.

The record name, sub-record types, and default collection period for service and network accounting policies are shown in Table 41. Table 43 (fields per policer stat-mode are given in the stat-mode command descriptions in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide), Table 44, and Table 45 provide field descriptions.

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.

Each accounting record name is composed of one or more sub-records which is in turn composed of multiple fields.

Refer to the Application Assurance Statistics Fields Generated per Record table in the 7450 ESS, 7750 SR, and VSR Multiservice Integrated Service Adapter and Extended Services Appliance Guide for fields names for Application Assurance records.

The availability of the records listed in Table 42 depends on the specific platform functionality and user configuration.

Table 43, Table 44, and Table 45 provide field descriptions.

* Enhanced Subscriber Management (ESM) only.

** Enhanced Subscriber Management (ESM) connection bonding only.

7.5.2. Accounting Files

When a policy has been created and applied to a service or network port, the accounting file is stored on the compact flash in a compressed XML file format. The router creates two directories on the compact flash to store the files. The following output displays a directory named act-collect that holds accounting files that are open and actively collecting statistics. The directory named act stores the files that have been closed and are awaiting retrieval.

Accounting files always have the prefix act followed by the accounting policy ID, log ID and timestamp. The accounting log file naming and log file destination properties like rollover and retention are discussed in more detail in Log Files.

7.5.3. Design Considerations for Accounting Policies

The router has ample resources to support large scale accounting policy deployments. When preparing for an accounting policy deployment, verify that data collection, file rollover, and file retention intervals are properly tuned for the amount of statistics to be collected.

If the accounting policy collection interval is too brief there may be insufficient time to store the data from all the services within the specified interval. If that is the case, some records may be lost or incomplete. Interval time, record types, and number of services using an accounting policy are all factors that should be considered when implementing accounting policies.

The rollover and retention intervals on the log files and the frequency of file retrieval must also be considered when designing accounting policy deployments. The amount of data stored depends on the type of record collected, the number of services that are collecting statistics, and the collection interval that is used. For example, with a 1Gb CF and using the default collection interval, the system is expected to hold 48 hours’ worth of billing information.

7.5.4. Reporting and Time-Based Accounting

SR OS on the 7750 SR platform has support for volume accounting and time-based accounting concepts, and provides an extra level of intelligence at the network element level in order to provide service models such as “prepaid access” in a scalable manner. This means that the network element gathers and stores per-subscriber accounting information and compares it with “pre-defined” quotas. Once a quota is exceeded, the pre-defined action (such as re-direction to a web portal or disconnect) is applied.

7.5.5. Overhead Reduction in Accounting: Custom Record

Custom records can be used to decrease accounting messaging overhead as follows:

7.5.6. Immediate Completion of Records

7.5.7. AA Accounting per Forwarding Class

This feature allows the operator to report on protocol/application/app-group volume usage per forwarding class by adding a bitmap information representing the observed FC in the XML accounting files. In case the accounted object is deleted or changed, the latest information will be written in the XML file with a “final” tag indication in the record header.