System management

This section describes the system information components.

The 7210 SAS routers are equipped with a real-time system clock for time-keeping purposes. When set, the system clock always operates on Coordinated Universal Time (UTC), but the software has options for local time translation and system clock synchronization. System time parameters include Time zones, Network Time Protocol, SNTP time synchronization, and CRON.

As more and more critical commercial applications move to IP networks, providing HA services becomes increasingly important. This section describes HA features for 7210 SAS devices.

This section describes the synchronization between the CPMs or CFMs.

Typically, the first Switch Fabric (SF) or CPM card installed in a redundant 7210 SAS-R6 and 7210 SAS-R12 chassis assumes the active CPM role, regardless of whether it is inserted in slot A or B. The next CPM installed in the same chassis then assumes the standby CPM role. If two CPMs are inserted simultaneously (or almost simultaneously) and boot at the same time, preference is given to the CPM installed in slot A.

If only one CPM is installed in a redundant 7210 SAS-R6 and 7210 SAS-R12, it becomes the active CPM regardless of the slot it is installed in.

To visually determine the active and standby designations, the Status LED on the faceplate is lit green (steady) to indicate the active designation. The Status LED on the second CPM faceplate is lit amber to indicate the standby designation.

A:7210SASR1# show card

===============================================================================
Card Summary
===============================================================================
Slot   Provisioned Type                            Admin Operational   Comments
           Equipped Type (if different)            State State
-------------------------------------------------------------------------------
1      imm-sas-10sfp+1xfp                          up    up
2      imm-sas-10sfp+1xfp                          up    up
A      cpm-sf-sas-R6                               up    up/active
B      cpm-sf-sas-R6                               up    up/standby
===============================================================================
A:7210SASR1#

...
Slot A contains the Active CPM

On the 7210 SAS-Sx/S 1/10GE configured in the standalone-VC mode, the user must designate and configure two nodes as CPM-IMM nodes. During boot up, one of the configured nodes assumes the active CPM role and the other assumes the standby CPM role. Typically, the configured CPMA-IMM node is favored to be the active CPM and the CPMB-IMM is favored to be the standby CPM. If only one CPM-IMM node is configured, it becomes the active CPM.

To visually determine the active and standby designations, the Master LED on the faceplate is lit (steady) to indicate the active designation. The Master LED on the standby CPM faceplate blinks to indicate the standby designation.

*A:CPM-A# show card
===============================================================================
Card Summary
===============================================================================
Slot      Provisioned Type                         Admin Operational   Comments
              Equipped Type (if different)         State State
-------------------------------------------------------------------------------
1         sas-s-48sfp-4sfpp                        up    up            CPMA-IMM
2         sas-s-24sfp-4sfpp                        up    up            CPMB-IMM
3         sas-s-24sfp-4sfpp                        up    up            IMM-ONLY
A         sfm-sas                                  up    up/active
B         sfm-sas                                  up    up/standby
===============================================================================
*A:CPM-A#

When an active CPM goes offline (due to reboot, removal, or failure), the standby CPM takes control without rebooting or initializing itself. It is assumed that the CPMs are synchronized, therefore, there is no delay in operability. When the CPM that went offline boots and comes back online, it becomes the standby CPM.

Active CPM in Slot A has stopped
Slot B is now active CPM


Attempting to exec configuration file:
'cf1:/config.cfg' ...

...

Executed 49,588 lines in 8.0 seconds from file cf1:\config.cfg

The following configuration guidelines apply when synchronizing the active and standby CPMs on the 7210 SAS-R6 and 7210 SAS-R12 systems:

• The active and standby CPM should boot from same boot drives (cf1:\, cf2:\, or uf:\). For example, if the active CPM is booted from cf1:\, the standby CPM must use cf1:\ to bootup. Although it is possible to make the CPMs operational by booting them using any drive on active and standby, Nokia recommends that the same drives should be used to boot the system.

• The user should ensure that a valid bootstrap image (boot.tim) and BOF (bof.cfg) exist in the cf1:\, cf2:\, or uf1:\ drive of both active and stand-by CPM cards. The user must verify that bof.cfg resides on the same drive as the boot.tim.

• The TiMOS application images (cpm.tim and iom.tim) and the configuration file can reside in any location (local or remote), but the locations in the BOF should be configured identically on both active and standby CPM for primary, secondary, and tertiary locations.

• Boot-env synchronization must be performed before config synchronization. To do so, run the admin redundancy synchronize boot-env command, followed by the admin redundancy synchronize config command.

• Synchronization can only occur locally between compact flash drives cf1:Active to cf1:Standby, cf2:Active to cf2:Standby, and uf1:Active to uf1:Standby. Synchronization across different drives is not supported.

• If the active and standby CPM are not synchronized for some reason, users can manually synchronize the standby CPM by running the admin redundancy synchronize boot-env CLI command, and rebooting the standby CPM by running the admin reboot standby command.

The timing subsystem has a central clock located on the CPM. The timing subsystem performs several functions of the network element clock as defined by Telcordia (GR-1244-CORE) and ITU-T G.781 standards.

The central clock uses the available timing inputs to train its local oscillator. The number of timing inputs available to train the local oscillator varies per platform. The priority order of these references must be specified. This is a simple ordered list of inputs: (ref1, ref2, BITS (if available)).

The CPM clock output can drive the clocking for all line cards in the system. The routers support selection of the node reference using Quality Level (QL) indications. The recovered clock can derive its timing from one of the references available on that platform.

The recovered clock can derive the timing from any of the following references (also shown in Logical model of synchronization reference selection on 7210 SAS):

• synchronous Ethernet ports

  On the 7210 SAS-T (includes all variants), 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (all variants), 7210 SAS-S 1/10GE (all variants), and 7210 SAS-Sx 10/100GE

• 1588v2/PTP timeReceiver port

  On the 7210 SAS-T (includes all variants), 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (all variants)

Logical model of synchronization reference selection on 7210 SAS shows a logical model of synchronization reference selection for the platforms, and Synchronization options for 7210 SAS platforms provides a list of supported interfaces for each platform.

On the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T, in addition to PTP and SyncE references, the recovered clock can be configured to derive the timing (frequency reference) from the BITS interface.

When quality Level (QL) selection mode is disabled, the reversion setting controls when the central clock can reselect a previously failed reference.

The following table lists the selection followed for two references in both revertive and non-revertive modes.

The following table lists the synchronization options supported on 7210 SAS platforms. The 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE, and 7210 SAS-Sx 10/100GE support these synchronization options only when operating in the standalone mode.

Synchronization Status Messages (SSM) are supported on devices that support Synchronous Ethernet. SSM allows the synchronization distribution network to determine the quality level of the clock sourcing a specific synchronization trail and also allows a network element to select the best of multiple input synchronization trails. SSMs are defined for various transport protocols (including SONET/SDH, T1/E1, and Synchronous Ethernet), for interaction with office clocks (such as BITS or SSUs) and embedded network element clocks.

SSM allows equipment to autonomously provision and reconfigure (by reference switching) their synchronization references, while helping to avoid the creation of timing loops. These messages are particularly useful for synchronization re-configurations when timing is distributed in both directions around a ring.

DS1 signals can carry the quality level value of the timing source information using the SSM that is transported within the 1544 kb/s signal Extended Super Frame (ESF) Data Link (DL), as described in ITU-T Recommendation G.704. No such provision is extended to SF formatted DS1 signals.

The format of the ESF DL messages is 0xxx xxx0 1111 1111, with the rightmost bit transmitted first. The 6 bits denoted by xxx xxx contain the message; some of these messages are reserved for synchronization messaging. It takes 32 frames (4 ms) to transmit all 16 bits of a complete DL.

E1 signals can carry the quality level value of the timing source information using the SSM, as described in ITU-T Recommendation G.704.

One of the Sa4 to Sa8 bits is allocated for SSMs; choosing the Sa bit that carries the SSM is user-configurable. To prevent ambiguities in pattern recognition, it is necessary to align the first bit (San1) with frame 1 of a G.704 E1 multiframe.

The San bits are numbered (n = 4, 5, 6, 7, 8). A San bit is organized as a 4-bit nibble San1 to San4. San1 is the most significant bit, and San4 is the least significant bit.

The message set in San1 to San4 is a copy of the set defined in SDH bits 5 to 8 of byte S1.

Traditionally, Ethernet-based networks employ a physical layer transmitter clock derived from an inexpensive +/-100ppm crystal oscillator and the receiver locks onto it. Because data is packetized and can be buffered, there is no need for long-term frequency stability or for consistency between frequencies of different links.

Synchronous Ethernet is a variant of the line timing that derives the physical layer transmitter clock from a high-quality frequency reference, replacing the crystal oscillator with a frequency source traceable to a primary reference clock. This change is transparent to the other Ethernet layers and does not affect their operation. The receiver at the far end of the link is locked to the physical layer clock of the received signal, and ensures access to a highly accurate and stable frequency reference. In a manner analogous to conventional hierarchical network synchronization, this receiver can lock the transmission clock of other ports to this frequency reference, and establish a fully time-synchronous network.

Unlike methods that rely on sending timing information in packets over an unclocked physical layer, Synchronous Ethernet is not affected by impairments introduced by higher levels of networking technology (packet loss, packet delay variation). The frequency accuracy and stability in Synchronous Ethernet typically exceeds networks with unsynchronized physical layers.

Synchronous Ethernet allows operators to gracefully integrate existing systems and future deployments into a conventional industry-standard synchronization hierarchy. The concept is analogous to SONET/SDH system timing capabilities. The operator can select any (optical) Ethernet port as a candidate timing reference. The recovered timing from this port is used to time the system (for example, the CPM will lock to this provisioned reference selection). The operator then can ensure that all system output is locked to a stable traceable frequency source.

Synchronous Ethernet using fixed copper ports is supported only on the 7210 SAS-T, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-S 1/10GE and 7210 SAS-Mxp. The fixed copper ports can be used as a candidate reference or for distribution of recovered reference . If the port is a fixed copper Ethernet port and in 1000 BASE-T mode of operation, there is a dependency on the 802.3 link timing for the Synchronous Ethernet functionality (see ITU-T G.8262). The 802.3 standard link timing states must align with the desired direction of Synchronous Ethernet timing flow. When a fixed copper Ethernet port is specified as an input reference for the node or when it is removed as an input reference for the node, an 802.3 link auto-negotiation is triggered to ensure the link timing aligns properly.

The SSM of Synchronous Ethernet uses an Ethernet OAM PDU that uses the slow protocol subtype. For a complete description of the format and processing, see ITU-T G.8264.

The Precision Time Protocol (PTP) is a timing-over-packet protocol defined in the IEEE 1588v2 standard 1588 PTP 2008.

PTP may be deployed as an alternative timing-over-packet option to ACR. PTP provides the capability to synchronize network elements to a Stratum-1 clock or primary reference clock (PRC) traceable source over a network that may or may not be PTP-aware. PTP has several advantages over ACR. It is a standards-based protocol, has lower bandwidth requirements, can transport both frequency and time, and can potentially provide better performance.

The basic types of PTP devices are the following:

• ordinary clock

• boundary clock

• end-to-end transparent clock

• peer-to-peer transparent clock

Synchronization options for 7210 SAS platforms lists the 7210 SAS platform support for the different types of PTP devices.

The 7210 SAS communicates with peer 1588v2 clocks, as shown in the following figure. These peers can be ordinary clock timeReceivers or boundary clocks. The communication can be based on either unicast IPv4 sessions transported through IP interfaces or Ethernet multicast PTP packets transported through an Ethernet port.

IP/UDP unicast and Ethernet multicast support for the 7210 SAS platforms is listed in the following table.

Unicast IP sessions support two types of peers: configured and discovered. The 7210 SAS operating as an ordinary clock timeReceiver or as a boundary clock must have configured peers for each PTP neighbor clock from which it might accept synchronization information. The 7210 SAS initiates unicast sessions with all configured peers. A 7210 SAS operating as a boundary clock accepts unicast session requests from external peers. If the peer is not configured, it is considered a discovered peer. The 7210 SAS can deliver synchronization information toward discovered peers (that is, timeReceivers).

For Ethernet multicast operation, the node listens for and transmits PTP messages using the configured multicast MAC address. Neighbor clocks are discovered via messages received through an enabled Ethernet port. The 7210 SAS supports only one neighbor PTP clock connecting into a single port (see Ethernet multicast ports); multiple PTP clocks connecting through a single port are not supported. This might be encountered with the deployment of an Ethernet multicast LAN segment between the 7210 SAS and the neighbor PTP ports using an end-to-end transparent clock or an Ethernet switch. The use of an Ethernet switch is not recommended because of PDV and potential performance degradation, but it can be used if appropriate for the application.

The 7210 SAS does not allow simultaneous PTP operations using both unicast IPv4 and Ethernet multicast. A change of profile to G.8275.1 or from G.8275.1 to another profile requires a reboot of the node.

The following figure shows one neighbor PTP clock connecting into a single port.

The IEEE 1588v2 standard includes the concept of PTP profiles. These profiles are defined by industry groups or standards bodies that define the use of IEEE 1588v2 for specific applications.

The following profiles are supported for 7210 SAS platforms (as described in IP/UDP unicast and Ethernet multicast support):

• IEEE 1588v2 (default profile)

• ITU-T Telecom profile (G.8265.1)

• ITU-T Telecom profile for time with full timing support (G.8275.1)

When a 7210 SAS receives Announce messages from one or more configured peers or multicast neighbors, it executes a Best timeTransmitter Clock Algorithm (BTCA) to determine the state of communication between itself and the peers. The system uses the BTCA to create a hierarchical topology, allowing the flow of synchronization information from the best source (the grandmaster clock) out through the network to all boundary and timeReceiver clocks. Each profile has a dedicated BTCA.

If the profile setting for the clock is "ieee1588-2008", the precedence order for the BTCA is as follows:

• priority1

• clock class

• clock accuracy

• PTP variance (offsetScaledLogVariance)

• priority2

• clock identity

• steps removed from the grandmaster

The 7210 SAS sets its local parameters as described in the following table.

If the profile setting for the clock is "itu-telecom-freq" (ITU G.8265.1 profile), the precedence order for the best timeTransmitter selection algorithm is:

• clock class

• PTSF (Packet Timing Signal Fail) - Announce Loss (miss 3 Announce messages or do not get an Announce message for 6 seconds)

• priority

The 7210 SAS sets its local parameters as described in the following table.

The ITU-T profile is for use in environments with only ordinary clock timeTransmitters and timeReceivers for frequency distribution.

If the profile setting for the clock is "g8275dot1-2014", the precedence order for the best timeTransmitter selection algorithm is very similar to that used with the default profile. It ignores the priority1 parameter, includes a localPriority parameter, and includes the ability to force a port to never enter the timeReceiver state (master-only). The precedence is as follows:

• clock class

• clock accuracy

• PTP variance (offsetScaledLogVariance)

• priority2

• localPriority

• clock identity

• steps removed from the grandmaster

The 7210 SAS sets its local parameters as described in the following table.

The 7210 SAS supports a limited number of configured (possible timeTransmitter or neighbor boundary clocks) and a discovered peers (timeReceivers).These peers use the unicast negotiation procedures to request service from the 7210 SAS clock. A neighbor boundary clock counts as two peers (both a configured and a discovered peer) toward the maximum limit.

The number of configured Ethernet ports is not restricted.

On the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T, there are limits on the number of timeReceivers enforced in the implementation for unicast and multicast timeReceivers.

The following figure shows the unicast negotiation procedure performed between a timeReceiver and a timeTransmitter clock that is selected to be the timeReceiver clock. The timeReceiver clock requests Announce messages from all peer clocks, but only requests Sync and Delay_Resp messages from the clock selected to be the timeTransmitter clock.

Although IEEE 1588v2 can function across a packet network that is not PTP-aware, performance may be unsatisfactory and unpredictable. PDV across the packet network varies with the number of hops, link speeds, utilization rates, and the inherent behavior of routers. By using routers with boundary clock functionality in the path between the grandmaster clock and the timeReceiver clock, one long path over many hops is split into multiple shorter segments, allowing better PDV control and improved timeReceiver performance. This allows PTP to function as a valid timing option in more network deployments and allows for better scalability and increased robustness in certain topologies, such as rings.

Boundary clocks can simultaneously function as a PTP timeReceiver of an upstream grandmaster (ordinary clock) or boundary clock, and as a PTP timeTransmitter of downstream timeReceivers (ordinary clock) and boundary clocks. The time scale recovered in the timeReceiver side of the boundary clock is used by the timeTransmitter side of the boundary clock. This allows time distribution across the boundary clock.

The following figure shows routers with boundary clock functionality in the path between grandmaster clock and the timeReceiver clock.

The 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 support 1PPS and 10 MHz output interfaces. These interfaces output the recovered signal from the system clock when PTP is enabled.

The following guidelines and restrictions apply for PTP configuration:

• On 7210 SAS devices, only a single profile (IEEE 1588v2, G.8265.1, or G.8275.1) can be enabled for all PTP communications (both towards its timeTransmitter and timeReceiver connections) at any point in time.

• The PTP G.8275.1 profile is supported only on the 7210 SAS-Mxp,7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T devices.

  On the 7210 SAS-R12, the G.8275.1 profile is supported only for IMMv2 cards.

  When using the G.8275.1 profile, the following restrictions apply:

  • The delay and sync requests are set to 16 pps by default and are not configurable.

  • The announce rate is set to 8 pps by default and is not configurable.

  • A change of profile to G.8275.1 or from G.8275.1 to another profile requires a reboot of the node.

  • Only a single multicast timeReceiver is supported per port.

• PTP with Ethernet encapsulation is supported only with the G.8275.1 profile.

• PTP over IP encapsulation is not supported with the G.8275.1 profile. It is supported only with the IEEE 1588v2 and G.8265.1 profiles.

• PTP timeReceiver capability is available on all the ports on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T.

• When changing the clock-type to or from a boundary clock on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T platforms, the node must be rebooted for the change to take effect. Nokia recommends taking appropriate measures to minimize service disruption during the reboot process.

• The 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, and 7210 SAS-T support the use of PTP and SyncE as a reference simultaneously. That is, on these 7210 SAS platforms, the ref-order can be set to config>system>sync-if-timing>ref-order ref1 ref2 ptp.

• The 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T support the PTP hybrid mode of operation. Frequency recovery is provided by the central clock through either SyncE or BITS, depending on which reference is configured. PTP is used for time recovery only. In this mode, the node can recover very stable frequency using a reduced PTP packet rate.

• To enable PTP hybrid mode on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, and 7210 SAS-T, run the config>system>ptp>clock>freq-source ssu CLI command. To enable pure PTP mode, the user must run the command config>system>ptp>clock>freq-source ptp.

  For a change of value from ssu to ptp (or vice-versa) to take effect, the operator must save the configuration changes and reboot the node.

• On the 7210 SAS-R6 and 7210 SAS-R12, only the BITS1 port can be used to provide a reference to the system clock or to distribute the reference. The use of the BITS2 port is not supported.

• On the 7210 SAS-T and 7210 SAS-Mxp, both the BITS1 and BITS2 ports can be used to provide a reference to the system clock or to distribute the reference.

• On the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, and 7210 SAS-T, an IP address must be configured under config>system>security>source-address>application ptp before PTP can be enabled for use. The use of the system IPv4 interface address or other loopback IPv4 interface address is recommended for PTP applications. The IPv4 address of an IPv4 interface over a port can also be used. The PTP software uses the configured IP address as the source IP address for both configured peers and discovered peers.

• On the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T, 1 pps and 10 MHz interface signals should only be used when PTP is enabled. Use these signals only after determining that the system is configured to use PTP as a reference and is locked to PTP.

• The 7210 SAS-S 1/10GE does not support IEEE 1588v2 PTP.

• On the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28, and 7210 SAS-T, PTP port-based timestamping is enabled by default on all ports for all PTP packets at system bootup:

  • When this feature is enabled, PTP packets are not forwarded transparently through the node, regardless of the service used and whether PTP is configured as a system clock reference. To enable transparent forwarding, see PTP message transparent forwarding.

  • Regardless of whether PTP is enabled (configure>sync-if-timing>ptp>no shutdown) or disabled (configure>sync-if-timing>ptp>shutdown), the timestamp value stored in the correction-field (CF) is updated for all PTP packets that are in transit through the node. This affects all PTP packets that are not originated or terminated on the node.

    To prevent this occurrence, disable PTP port-based hardware timestamps on specific (all or select) ports by configuring the configure>port>no ptp-hw-timestamp CLI command on ports where PTP packets are in transit. When the feature is disabled, PTP packets in transit are transparently forwarded without changing the timestamp value.

The 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, and 7210 SAS-T support the configuration of PTP and SyncE references at the same time. On these platforms, ref-order can be set to config>system>sync-if-timing>ref-order ref1 ref2 ptp.

*A:SAS-T-B>config>system>sync-if-timing# info detail 
----------------------------------------------
            ql-selection
            ref-order ptp ref1 ref2 --
> All three reference can be configured simultaneously
            ref1
                source-port 1/1/1
                no shutdown
                no ql-override
            exit
            ref2
                source-port 1/1/7
                no shutdown
                no ql-override
            exit
            ptp
                no ql-override
                no shutdown
            exit
            revert
----------------------------------------------

In previous releases, the system statically allocated ingress TCAM resources for use by SAP ingress QoS classification, SAP ingress access control list (ACLs), identifying and sending CFM OAM packets to CPU for local processing, and so on. The resource allocation is not user-configurable. With the introduction of new capabilities including IPv6 classification, UP MEP support, and G8032-fast-flood, the static allocation of resources by software does not meet requirements of customers who typically want to use different features.

The user can allocate a fixed amount of resources per system (or per card on 7210 SAS-R6 and 7210 SAS-R12 devices) for QoS, ACLs, CFM/Y.1731 MEPs and other features. Of these, some parameters are boot-time parameters and others are run-time. A change in the current value of a boot-time parameter needs a node reboot or, on 7210 SAS-R6 and 7210 SAS-R12 devices, a card reset using the reset command, before the new value takes effect. Change in the current value of a parameter that is designated run-time takes effect immediately if the software determines that resources are available for use to accommodate the change.

On the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T, the system resource profile parameters are available using the config>system>resource-profile CLI context and the defined parameters are applicable to the entire node. On the 7210 SAS-R6 and 7210 SAS-R12, the parameters are defined as a system resource profile policy that the user must configure and associate with the IMM. The software reads the configured policy and allocates resources appropriately per IMM, allowing users to allocate resources to different features per IMM. On the 7210 SAS-R6 and 7210 SAS-R12, some system resource profile parameters apply to the entire node and not just the IMM. For more information, see System resource-profile router commands for 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T.

During bootup, the system reads the resource profile parameters and allocates resources to features in the order they appear in the configuration file.

Because resources are shared, the user must ensure that the sum total of such resources does not exceed the limit supported by the IMM or node. If the system determines that it cannot allocate the requested resources, the feature is disabled. For example, if the system determines that it cannot allocate resources for g8032-fast-flood, it disables the feature from use and G8032 eth-rings will not be able to use fast-flood mechanisms). Another example is the case where the system determines that it cannot allocate resources for IPv4-based SAP Ingress ACL classification, the system will not allow users to use IPv4-based SAP ingress ACL classification feature and fails the configuration when it comes upon the first SAP in the configuration file that uses an IPv4-based SAP ingress ACL policy.

For boot-time parameters, such as g8032-fast-flood-enable, the user must ensure that the configured services match the resources allocated. If the system determines that it cannot allocate resources to services, it fails the configuration file at the first instance where it encounters a command to which resources cannot be allocated. The available resources can be allocated to different features.

For ACL and QoS resources, the user has the option to allocate resources to limit usage per feature, regardless of the match criteria used. The sum of all resources used for different SAP ingress classification match-criteria is limited by the amount of resources allocated for SAP ingress classification. The user can also allocate resources by specific match criteria. The user can enable any supported match criteria and associate a fixed amount of resources with each match criteria in fixed sizes; the chunk size is dependent on the platform.

The system allocates resources based on the order of appearance in the configuration file, and fails any match criteria if the system does not have any more resources to allocate. In addition, the max keyword can be used to indicate that the system needs to allocate resources when they are first required, as long as the maximum amount of resources allocated for that feature is not exceeded or the maximum amount of resources available in the system is not exceeded. The 7210 SAS platforms allocate resources to each feature and match-criteria in fixed-size chunks.

The no form of the resource-profile command disables the use of the corresponding match criteria or feature by deallocating all the resources allocated to the criteria or feature. For example:

1. Configuring the system resource-profile internal-ingress-tcam qos-sap-ingress-resource no mac-match-enable command deallocates all the resources allocated to SAP ingress QoS classification MAC match criteria. After this command is run, users cannot associate a SAP ingress policy with MAC match criteria defined to a SAP. Resources allocated to other criteria are unaffected and can continue to be used.

2. Configuring the system resource-profile internal-ingress-tcam eth-cfm no up-mep command deallocates all the resources allocated to CFM UP MEP. After this command is run, user cannot configure UP MEP.

If the system successfully runs the no command, it frees up resources used by the chunk or slice and make the resources, or the entire chunk/slice, available for use by other features. Before deallocating resources, the software checks if a service object is using the resource and fails the command if the object is in use. If resources are in use, they can be freed up by deleting a SAP, removing a policy association with a SAP, deleting a MEP, and so on. Some commands under the system resource-profile context do not take effect immediately and require a system reboot before the change occurs and resources are freed. The following is the handling of freed resources:

• If some entries in a slice are freed, they are made available for use by other SAPs using the same feature to which the chunk is allocated.

• If an entire chunk is freed, it is returned to the system free pool for possible use by other features.

For more information about specific CLI commands and features that use system resource allocation, see the CLI command and feature descriptions in the appropriate 7210 SAS software user manual.

Before the introduction of new capabilities, such as IPv6 match criteria, the system allocated egress TCAM resources on bootup for use by different criteria in SAP egress access control lists (ACLs) and other purposes; the resource allocation was not user configurable. With the introduction of new capabilities, such as IPv6 match criteria in egress, the static allocation of resources by software may not meet customer requirements if they want to use different features. Therefore, to facilitate user configuration and resource allocation in accordance with user needs, the ingress internal TCAM resource allocation capabilities have been extended to include the egress internal TCAM resources.

For information about specific CLI commands and features that use system resource allocation, see the CLI command and feature descriptions in the appropriate 7210 SAS software user manuals.

This section provides system resource allocation examples.

config> system> resource-profile...
...
   acl-sap-ingress 3
      mac-match-enable max
      ipv4-match-enable 1
      no ipv6_128-ipv4-match-enable
      no ipv6_64-only-match-enable
   exit
...

config> system> resource-profile>
...
   acl-sap-ingress 3
      mac-match-enable max
      ipv4-match-enable 1
      no ipv6_128-ipv4-match-enable
      ipv6_64-only-match-enable max
   exit
...

The following configuration guidelines apply to 7210 SAS-R6 and 7210 SAS-R12:

• The user can change the system-resource policy attached to a card/IMM in the following cases:

  • when the card/IMM state is unprovisioned

  • when the card/IMM is provisioned but not equipped

  • when the card/IMM is provisioned and equipped, but there is a mismatch between the two

• Upon provisioning the card, subsequent to attaching a new system-resource policy, the parameters specified in the policy are used (including any boot-time parameters).

• If the card is provisioned and equipped, and any boot-time parameter is changed in the system-resource policy, the user must issue the card reset command for all cards that are using the policy or reboot the chassis, for the policy change to take effect.

This section describes the basic system information parameters to configure the physical location of the router, contact information, location information for the router such as an address, floor, and room number, global positioning system (GPS) coordinates, and system name.

Use the CLI syntax displayed in this section to configure the system information parameters.

The config-backup command allows you to specify the maximum number of backup versions of the configuration and index files kept in the primary location.

For example, assume the config-backup count is set to "5" and the configuration file is named xyz.cfg. When a save command is issued, the xyz.cfg file is saved with a .1 extension. Each subsequent config-backup command increments the numeric extension until the maximum count is reached. The oldest file ("5") is deleted as more recent files are saved.

xyz.cfg

xyz.cfg.1

xyz.cfg.2

xyz.cfg.3

xyz.cfg.4

xyz.cfg.5

xyz.ndx

Each persistent index file is updated at the same time as the associated configuration file. When the index file is updated, the save is performed to xyz.cfg and the index file is created as xyz.ndx. Synchronization between the active and standby is performed for all configurations and their associated persistent index files.

Use the following syntax to specify the maximum number of backup versions of the configuration and index files kept in the primary location.

config>system
        config-backup count

config>system# 
    config>system# config-backup 7

A:ALA-12>config>system>time# info
#------------------------------------------
echo "System Configuration"
#------------------------------------------
        name "ALA-12"
        contact "Fred Information Technology"
        location "Bldg.1-floor 2-Room 201"
        clli-code "abcdefg1234"
        coordinates "N 45 58 23, W 34 56 12"
        config-backup 7
...
----------------------------------------------
A:ALA-12>config>system>time#

The disconnect command immediately disconnects a user from a console, Telnet, FTP, or SSH session.

Use the following syntax to disconnect a user from a session.

admin
        disconnect [address ip-address |username user-name |{console|telnet|ftp|ssh}]

	admin# disconnect 

ALA-1>admin# disconnect
ALA-1>admin# Logged out by the administrator
Connection to host lost.

C:\>

Use the set-time command to set the system date and time. The time entered should be accurate for the time zone configured for the system. The system will convert the local time to UTC before saving to the system clock, which is always set to UTC. If SNTP or NTP is enabled (no shutdown), this command cannot be used. The set-time command does not take into account any daylight saving offset, if defined.

Use the following syntax to set the date and time.

admin
        set-time date time

admin# set-time 2007/02/06 04:10:00

ALA-2# admin set-time 2007/02/06 04:10:00
ALA-2# show time
Thu Feb 2 04:10:04 GMT 2007
ALA-2#

The display-config command displays the running configuration of the system.

Use the following syntax to display the running configuration of the system.

admin
        display-config [detail] [index]

admin# display-config detail

A:ALA-12>admin# display-config detail
#------------------------------------------
echo "System Configuration"
#------------------------------------------
    system
        name "ALA-12"
        contact "Fred Information Technology"
        location "Bldg.1-floor 2-Room 201"
        clli-code "abcdefg1234"
        coordinates "N 45 58 23, W 34 56 12"
        config-backup 7
        boot-good-exec "ftp://test:test@192.168.xx.xxx/./1xx.cfg.A"
        boot-bad-exec "ftp://test:test@192.168.xx.xxx/./1xx.cfg.1"
        lacp-system-priority 1
        no synchronize
        snmp
            shutdown
            engineID "0000197f000000000467ff00"
            packet-size 1500
            general-port 161
        exit
        login-control
            ftp
                inbound-max-sessions 3
            exit
            telnet
                inbound-max-sessions 5
                outbound-max-sessions 2
            exit
            idle-timeout 1440
            pre-login-message "Property of Service Routing Inc.
                               Unauthorized access prohibited."
            motd text "Notice to all users: Software upgrade scheduled 
                       3/2 1:00 AM"
        exit
        security
            management-access-filter
                default-action permit
                entry 1
                    no description
...

The tech-support command creates a system core dump.

The save command saves the running configuration to a configuration file. If the debug-save parameter is specified, debug configurations are saved in the configuration file; otherwise, the debug configurations are not saved between reboots.

Use the following syntax to save the running configuration.

admin
    save [file-url][detail][index]
    debug-save [file-url]

admin# save ftp://test:test@192.168.x.xx/./1.cfg
    admin# debug-save debugsave.txt

A:ALA-1>admin# save ftp://test:test@192.168.x.xx/./1x.cfg
Writing file to ftp://test:test@192.168.x.xx/./1x.cfg
Saving configuration ...Completed.
ALA-1>admin# debug-save ftp://test:test@192.168.x.xx/./debugsave.txt
Writing file to ftp://julie:julie@192.168.x.xx/./debugsave.txt
Saving debug configuration .....Completed.
A:ALA-1>admin#

The reboot command reboots the router including redundant cards in redundant systems. If the now option is not specified, you are prompted to confirm the reboot operation. The reboot upgrade command forces an upgrade of the device firmware (CPLD and ROM) and reboots.

Use the following syntax to reboot the router.

admin
        reboot [upgrade][auto-init][now]

	admin# reboot now

A:ALA-1>admin# reboot now
Are you sure you want to reboot (y/n)? y
Rebooting...
Using preloaded VxWorks boot loader.
...

admin# reboot auto-init [now]

Example: *A:ALA-1# admin reboot auto-init 
WARNING: Configuration and/or Boot options may have changed since the last save.
Are you sure you want to reset the bof and reboot (y/n)? Y 
Resetting...OK

Nokia 7210 Boot ROM. Copyright 2016 Nokia.
All rights reserved. All use is subject to applicable license agreements.

Two post-boot configuration extension files are supported and are triggered when either a successful or failed boot configuration file is processed. The commands specify URLs for the CLI scripts that are run following the completion of the boot-up configuration. A URL must be specified or no action is taken. The commands are persistent between router reboots and are included in the configuration saves (admin>save).

Use the following syntax to configure a URL for a CLI script that runs when the boot-up configuration is completed.

config>system 
            boot-bad-exec file-url
            boot-good-exec file-url          

config>system# boot-bad-exec ftp://test:test@192.168.xx.xxx/./fail.cfg
config>system# boot-good-exec ftp://test:test@192.168.xx.xxx/./ok.cfg

*A:ALA# configure system 
*A:ALA>config>system# info 
----------------------------------------------
#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
        name "ALA"
        boot-good-exec "cf1:\good.cfg"
        boot-bad-exec "cf1:\bad.cfg"
        snmp
            shutdown
        exit
        login-control
            idle-timeout disable
            pre-login-message "ala-1" name
        exit
        time
            ntp
                authentication-key 1 key "SV3BxZCsIvI" hash type message-digest 
                server 10.135.16.130 
                peer 10.0.0.1 key-id 1 
                no shutdown
            exit
            sntp
                server-address 10.135.16.90 preferred 
                no shutdown           
            exit
            zone UTC 
        exit
        thresholds
            rmon
            exit
        exit
#--------------------------------------------------
echo "System Security Configuration"
#--------------------------------------------------
        security
            hash-control read-version all write-version 1 
            telnet-server
            ftp-server
            snmp
                community "private" rwa version both
                community "public" r version both
            exit
            source-address
                application ftp 10.135.16.97
                application snmptrap 10.135.16.97
                application ping 10.135.16.97
                application dns 10.135.16.97
            exit
        exit
----------------------------------------------
*A:ALA>config>system#

This section describes the CLI command syntax to enable synchronous Ethernet on specific 7210 SAS platforms.

To enter edit mode and edit timing references, enter the begin keyword at the config>system>sync-if-timing# prompt.

Use the following CLI syntax to enter the edit mode.

config>system>sync-if-timing
    begin

A:ALA-12>config>system>sync-if-timing>ref1# source-port 2/1/1
MINOR: CLI The sync-if-timing must be in edit mode by calling begin before any
 changes can be made.
MINOR: CLI Unable to set source port for ref1 to 2/1/1.
A:ALA-12>config>system>sync-if-timing>ref1#

The revert command allows the clock to revert to a higher-priority reference if the current reference goes offline or becomes unstable.

If revertive switching is enabled, the highest-priority valid timing reference is used. If a reference with a higher priority becomes valid, a switchover to that reference is initiated. If a failure on the current reference occurs, the next highest reference takes over.

If non-revertive switching is enabled, the active reference always remains selected while it is valid, even if a higher priority reference becomes available. If the active reference becomes invalid, a reference switchover to a valid reference with the highest priority is initiated. The failed reference is eligible for selection when it becomes operational.

Use the following syntax to revert the clock to a higher priority reference.

config>system>sync-if-timing 
        revert

Other editing commands are:

• commit

  Saves changes made to the timing references during a session. Modifications are not persistent across system boots unless this command is entered.

• abort

  Discards changes that have been made to the timing references during a session.

Use the following syntax to abort or commit changes made to a timing reference.

config>system>sync-if-timing
        abort
        commit

You can force the system synchronous timing output to use a specific reference.

When the debug sync-if-timing force-reference command is run, the current system synchronous timing output is immediately referenced from the specified reference input. The reference must be qualified.

Debug configurations are not saved between reboots.

Use the following syntax to reference the current system synchronous timing output from the specifies reference input.

debug>sync-if-timing
        	force-reference {ref1 | ref2}

debug>sync-if-timing# force-reference

The event command controls the generation and notification of threshold crossing events configured with the alarm command. When a threshold crossing event is triggered, the rmon event configuration optionally specifies whether an entry in the RMON-MIB log table will be created to record the event. It can also specify whether an SNMP notification (trap) will be generated for the event. There are two notifications for threshold crossing events; a rising alarm and a falling alarm.ping-address.

Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the 7210 SAS event logs. However, when the event is set to trap, the generation of a rising alarm or falling alarm notification creates an entry in the event logs and that is distributed to the configured log destinations, including console, session, memory, file, syslog, or SNMP trap destination. The logger message includes a rising or falling threshold crossing event indicator, the sample type (absolute or delta), the sampled value, the threshold value, the rmon-alarm-id, the associated rmon-event-id, and the sampled SNMP object identifier.

The alarm command configures an entry in the RMON-MIB alarm table. The alarm command controls the monitoring and triggering of threshold crossing events. To trigger the notification or logging of a threshold crossing event, at least one associated rmon event must be configured.

The agent periodically takes statistical sample values from the MIB variable specified for monitoring and compares them to thresholds that have been configured with the alarm command. The alarm command configures the MIB variable to be monitored, the polling period (interval), sampling type (absolute or delta value), and rising and falling threshold parameters. If a sample has crossed a threshold value, the associated event is generated.

Preconfigured CLI threshold commands are available. Preconfigured commands hide some of the complexities of configuring RMON alarm and event commands and perform the same function. In particular, the preconfigured commands do not require the user to know the SNMP object identifier to be sampled. The preconfigured threshold configurations include memory warnings, alarms, and compact flash usage warnings and alarms.

config>system>thresholds# cflash-cap-warn cf1-B: rising-threshold 2000000 falling-threshold 1999900 interval 240 trap startup-alarm either

config>system>thresholds# memory-use-alarm rising-threshold 50000000 falling-threshold 45999999 interval 500 both startup-alarm either

config>system>thresh# rmon

config>system>thresh>rmon# event 5 both description "alarm testing" owner "Timos CLI"

A:ALA-49>config>system>thresholds# info
----------------------------------------------
            rmon
                event 5 description "alarm testing" owner "Timos CLI"
            exit
            cflash-cap-warn cf1-B: rising-threshold 2000000 falling-
                                   threshold 1999900 interval 240 trap
            memory-use-alarm rising-threshold 50000000 falling-
                                   threshold 45999999 interval 500
----------------------------------------------
A:ALA-49>config>system>thresholds#

7210 SAS hardware supports alarm contact inputs that allow the operator to monitor and report changes in external environmental conditions. In a remote or outdoor deployment, alarm contact inputs allow the operator to detect conditions, for example, air conditioner fault, open door.

You can configure generation of events when alarm contact inputs transition between the open and close states. For each generated event, you can specify the following:

• action associated with each state transition

• severity associated with each state transition

• log message associated with each state transition