System management

This chapter provides information about configuring basic system management parameters.

System management parameters

System management commands allow you to configure basic system management functions such as the system name, the router’s location and coordinates, and Common Language Location Identifier (CLLI) code, as well as time zones, Network Time Protocol (NTP), Simple Network Time Protocol (SNTP) properties, CRON and synchronization properties.

System information

This section describes the system information components.

System name

The system name is the MIB II (RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)) sysName object. By convention, this text string is the fully-qualified domain name of the node. The system name can be any ASCII printable text string up to 32 characters.

System contact

The system contact is the MIB II sysContact object. By convention, this text string is a textual identification of the contact person for this managed node, together with information about how to contact this person. The system contact can be any ASCII printable text string up to 80 characters.

System location

The system location is the MIB II sysLocation object, which is a text string conventionally used to describe the physical location of the node; for example, ‟Bldg MV-11, 1st Floor, Room 101”. The system location can be any ASCII printable text string up to 80 characters.

System coordinates

The Nokia Chassis MIB tmnxChassisCoordinates object defines the system coordinates. This text string indicates the Global Positioning System (GPS) coordinates of the location of the chassis.

Two-dimensional GPS positioning offers latitude and longitude information as a four dimensional vector:

<direction, hours, minutes, seconds>

where:

  • direction is one of the four basic values: N, S, W, E

  • hours ranges from 0 to 180 (for latitude) and 0 to 90 for longitude

  • minutes and seconds range from 0 to 60.

<W, 122, 56, 89> is an example of longitude and <N, 85, 66, 43> is an example of latitude.

System coordinates can be expressed in different notations; for example:

  • N 45 58 23, W 34 56 12

  • N37 37' 00 latitude, W122 22' 00 longitude

  • N36*39.246' W121*40.121

The system coordinates can be any ASCII printable text string up to 80 characters.

Naming objects

It is discouraged to configure named objects with a name that starts with ‟tmnx” and with the ‟_” symbol.

CLLI

A CLLI code string for the device is an 11-character standardized geographic identifier that uniquely identifies the geographic location of places and certain functional categories of equipment unique to the telecommunications industry. The CLLI code is stored in the Nokia Chassis MIB tmnxChassisCLLICode object.

The CLLI code can be any ASCII printable text string of up to 11 characters.

System time

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.

Time zones

Setting a time zone allows times to be displayed in the local time rather than in UTC. The supports both user-defined and system-defined time zones.

A user-defined time zone has a user-assigned name of up to four printable ASCII characters that is different from the system-defined time zones. For user-defined time zones, the offset from UTC is configured, as well as any summer time adjustment for the time zone.

The system-defined time zones are listed in the following table, which includes both time zones with and without summer time correction.

Table 1. System-defined time zones

Acronym

Time zone name

UTC offset

Europe

GMT

Greenwich Mean Time

UTC

BST

British Summer Time

UTC +1

IST

Irish Summer Time

UTC +1*

WET

Western Europe Time

UTC

WEST

Western Europe Summer Time

UTC +1

CET

Central Europe Time

UTC +1

CEST

Central Europe Summer Time

UTC +2

EET

Eastern Europe Time

UTC +2

EEST

Eastern Europe Summer Time

UTC +3

MSK

Moscow Time

UTC +3

MSD

Moscow Summer Time

UTC +4

US and Canada

AST

Atlantic Standard Time

UTC -4

ADT

Atlantic Daylight Time

UTC -3

EST

Eastern Standard Time

UTC -5

EDT

Eastern Daylight Saving Time

UTC -4

ET

Eastern Time

Either as EST or EDT, depending on place and time of year

CST

Central Standard Time

UTC -6

CDT

Central Daylight Saving Time

UTC -5

CT

Central Time

Either as CST or CDT, depending on place and time of year

MST

Mountain Standard Time

UTC -7

MDT

Mountain Daylight Saving Time

UTC -6

MT

Mountain Time

Either as MST or MDT, depending on place and time of year

PST

Pacific Standard Time

UTC -8

PDT

Pacific Daylight Saving Time

UTC -7

PT

Pacific Time

Either as PST or PDT, depending on place and time of year

HST

Hawaiian Standard Time

UTC -10

AKST

Alaska Standard Time

UTC -9

AKDT

Alaska Standard Daylight Saving Time

UTC -8

Australia

AWST

Western Standard Time (for example, Perth)

UTC +8

ACST

Central Standard Time (for example, Darwin)

UTC +9.5

AEST

Eastern Standard/Summer Time (for example, Canberra)

UTC +10

Network Time Protocol

The Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. It allows participating network nodes to keep time more accurately and maintain time in a more synchronized manner between the participating network nodes.

NTP uses stratum levels to define the number of hops from a reference clock. The reference clock is treated as a stratum-0 device that is assumed to be accurate with little or no delay. Stratum-0 servers cannot be used in a network. However, they can be directly connected to devices that operate as stratum-1 servers. A stratum-1 server is an NTP server with a directly-connected device that provides Coordinated Universal Time (UTC), such as a GPS or atomic clock.

The 7210 SAS devices cannot act as stratum-1 servers but can act as stratum-2 devices because a network connection to an NTP server is required.

The higher stratum levels are separated from the stratum-1 server over a network path, therefore a stratum-2 server receives its time over a network link from a stratum-1 server. A stratum-3 server receives its time over a network link from a stratum-2 server.

If the internal PTP process is used as a time source for System Time and OAM, it must be specified as a server for NTP. If PTP is specified, the prefer parameter must also be specified. After PTP has established a UTC traceable time from an external grandmaster source, that clock will always be the time source into NTP, even if PTP goes into time holdover.

Note:

Use of the internal PTP time source for NTP promotes the internal NTP server to stratum 1 level. This may impact the NTP network topology.

The following NTP elements are supported:

  • server mode

    In this mode, the node advertises the ability to act as a clock source for other network elements. By default, the node will, by default, transmits NTP packets in NTP version 4 mode.

  • authentication keys

    These keys implement increased security support in carrier and other networks. Both DES and MD5 authentication are supported, as well as multiple keys.

  • symmetric active mode

    In this mode, the NTP is synchronized with a specific node that is considered more trustworthy or accurate than other nodes carrying NTP in the system. This mode requires that a specific peer is set.

  • broadcast

    In this mode, the node receives or sends using a broadcast address.

  • alert when NTP server is not available

    When none of the configured servers are reachable on the node, the system reverts to manual timekeeping and issues a critical alarm. When a server becomes available, a trap is issued indicating that standard operation has resumed.

  • NTP and SNTP

    If both NTP and SNTP are enabled on the node, SNTP transitions to an operationally down state. If NTP is removed from the configuration or shut down, SNTP resumes an operationally up state.

  • gradual clock adjustment

    Because several applications (such as Service Assurance Agent (SAA)) can use the clock, if a major adjustment (128 ms or more) is needed, it is performed by programmatically stepping the clock. If a minor (less than 128 ms) adjustment is needed, it is performed by either speeding up or slowing down the clock.

  • rate limit events and traps

    To avoid the generation of excessive events and traps the NTP module rate limits the generation of events and traps to three per second. At that point, a single trap is generated to indicate that event and trap squashing is taking place.

SNTP time synchronization

To synchronize the system clock with outside time sources, the 7210 SAS devices include a Simple Network Time Protocol (SNTP) client. As defined in RFC 2030, SNTP Version 4 is an adaptation of NTP. SNTP typically provides time accuracy within 100 ms of the time source. SNTP can only receive the time from NTP servers; it cannot be used to provide time services to other systems. SNTP is a compact, client-only version of NTP. SNTP does not authenticate traffic.

In the 7210 SAS software, the SNTP client can be configured in both unicast client modes (point-to-point) and broadcast client modes (point-to-multipoint). SNTP should be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the highest stratum (leaves) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP time servers should operate only at the root (stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio clock is available.

CRON

The CRON feature supports the SAA functions and time-based policy scheduling to meet time of day requirements. CRON functionality includes the ability to specify the commands to be run, their scheduling, including one-time only functionality (oneshot), interval and calendar functions, and the storage location for the script output. CRON can also specify the relationship between input, output, and schedule. Scheduled reboots, peer turn ups, service assurance agent tests, and OAM events, such as connectivity checks or troubleshooting runs, can also be scheduled.

CRON features are saved to the configuration file.

CRON features run serially with at least 255 separate schedules and scripts. Each instance can support a schedule where the event is repeatedly executed.

The following CRON elements are supported:

  • action

    This configures parameters for a script including the maximum amount of time to keep the results from a script run, the maximum amount of time a script may run, the maximum number of script runs to store and the location to store the results.

  • schedule

    The schedule function configures the type of schedule to run, including one-time only (oneshot), periodic, or calendar-based runs. All runs are determined by month, day of month or weekday, hour, minute and interval (seconds).

  • script

    The script command opens a new nodal context that contains information about a script.

  • time range

    ACLs and QoS policy configurations may be enhanced to support time-based matching. CRON configuration includes time-matching with the schedule sub-command. Schedules are based on events; time-range defines an end-time used as a match criteria.

  • time of day

    Time of Day (TOD) suites are useful when configuring many types of time-based policies or when a large number of SAPs require the same type of TOD changes. The TOD suite may be configured while using specific ingress or egress ACLs or QoS policies, and is an enhancement of the ingress and egress CLI trees.

High availability

This section describes the high availability (HA) routing options and features that service providers can use to reduce vulnerability at the network or service provider edge and alleviate the effect of a lengthy outage on IP networks.

Note:

HA with control plane redundancy is only supported on the 7210 SAS-R6 and 7210 SAS-R12. Control plane redundancy is not supported on the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-T.

HA is an important feature in service provider routing systems. The unprecedented growth of IP services and applications in service provider networks is driven by the demand from the enterprise and residential communities. Downtime can be very costly, and, in addition to lost revenue, customer information and business-critical communications can be lost. HA is the combination of continuous uptime over long periods (Mean Time Between Failures (MTBF)) and the speed at which failover or recovery occurs (Mean Time To Repair (MTTR)).

The advantage of HA routing is evident at the network or service provider edge, where thousands of connections are hosted. Rerouting options around a failed piece of equipment are often limited, or, a single access link exists to a customer because of the additional cost of redundant links. As service providers converge business-critical services, such as real-time voice (VoIP), video, and VPN applications over their IP networks, the requirements for HA become more stringent compared to the requirements for best-effort data.

Network and service availability become critical aspects in advanced IP service offerings, which dictate that the IP routers used to build the foundations of these networks must be resilient to component and software outages.

HA features

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.

Redundancy

Redundancy features enable duplication of data elements to maintain service continuation in case of outages or component failure.

Software redundancy on 7210 SAS-R6 and 7210 SAS-R12

Software outages are challenging even when baseline hardware redundancy is in place. A balance should be maintained when providing HA routing, otherwise router problems typically propagate not only throughout the service provider network, but also externally to other connected networks that potentially belong to other service providers. This could affect customers on a broad scale. The 7210 SAS-R6 and 7210 SAS-R12 devices support several software availability features that contribute to the percentage of time that a router is available to process and forward traffic.

All routing protocols specify minimum time intervals in which the peer device must receive an acknowledgment before it disconnects the session:

  • OSPF default session timeout is approximately 40 seconds. The timeout intervals are configurable.

  • BGP default session timeout is approximately 120 seconds. The timeout intervals are configurable.

Therefore, router software must recover faster than the specified time interval to maintain up time.

Configuration redundancy on 7210 SAS-R6 and 7210 SAS-R12

Features configured on the active device CFM or CPM are also saved on the standby CFM or CPM. If the active device CFM or CPM fails, these features are brought up on the standby device that takes over the mastership and becomes the active CFM or CPM.

Even with modern modular and stable software, the failure of route processor hardware or software can cause the router to reboot or cause other service impacting events. In the best circumstances, failure leads to the initialization of a redundant route processor, which hosts the standby software configuration, to become the active processor. The following options are available:

  • warm standby

    The router image and configuration is already loaded on the standby route processor. However, the standby could still take a few minutes to become effective because it must first reinitialize connections by bringing up Layer 2 connections and Layer 3 routing protocols, and then rebuild the routing tables.

  • hot standby

    The router image, configuration, and network state are already loaded on the standby; it receives continual updates from the active route processor and the swap-over is immediate. Newer generation routers, like the 7210 SAS routers have extra processing built into the system so that router performance is not affected by frequent synchronization, which consumes increased system resources.

Component redundancy

7210 SAS component redundancy is critical to reducing MTTR for the routing system.

Note:

This feature is supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.

Component redundancy consists of the following:

  • redundant power supply

    The use of 2 power supplies is supported for redundant power supplies. A power module can be removed without impact on traffic when redundant power supplies are in use. The power supply is hot swappable. The 7210 SAS-S 1/10GE platform supports a single fixed non-removable integrated power supply and a hot-swappable power supply.

    Note:
    • On the 7210 SAS-S 1/10GE platform, if the device is booted with a power entry module and there is a power supply, the system detects the power supply. If the device is booted with a power entry module but there is no power supply, the system does not detect the ‟power-supply type”. This occurrence is reported as none and the PS LED is OFF.

    • On the 7210 SAS-S 1/10GE platform, there is no DC input failure detection that is classified separately. In the case of a failure, the system reports the DC power value as ‟failed.”

  • fan module

    Failure of one or more fans does not impact traffic. Failure of a single fan is detected and notified. The fan tray and fan module is hot-swappable:

    • On the 7210 SAS-R6 and 7210 SAS-R12, the fan module/tray contains 6 fans.

    • On the 7210 SAS-Mxp and 7210 SAS-T, the fan module/tray contains 3 fans.

    • On the 7210 SAS-Sx 1/10GE and 7210 SAS-Sx 10/100GE, the fan module is not supported. The devices contain a fixed set of one or more fans with filters on both sides of the chassis.

    • On the 7210 SAS-S 1/10GE, the fan module is not supported. The devices contain a fixed set of one or more fans without filters.

    • On the 7210 SAS-R6 and 7210 SAS-R12, 2 x Switch Fabric/Control Processor Module (SF/CPM) can be used to provide control plane redundancy with non-stop routing and non-stop services. The SF/CPM is hot-swappable.

Service redundancy on 7210 SAS-R6 and 7210 SAS-R12

All service-related statistics are kept during a switchover. Services, SDPs, and SAPs will remain up with a minimum loss of forwarded traffic during a CFM/CPM switchover.

Accounting configuration redundancy on 7210 SAS-R6 and 7210 SAS-R12

When there is a switchover and the standby CFM/CPM becomes active, the accounting servers are checked and if they are administratively up and capable of coming online (media present, and others), the standby is brought online; new accounting files are created at this point. Users must manually copy the accounting records from the failed CFM/CPM.

Nonstop forwarding and routing on 7210 SAS-R6 and 7210 SAS-R12

In a control plane failure or a forced switchover event, the router continues to forward packets using the existing stale forwarding information. Nonstop forwarding requires clean control plane and data plane separation. Usually the forwarding information is distributed to the IMMs.

Nonstop forwarding on 7210 SAS-R6 and 7210 SAS-R12

In a control plane failure or a forced switchover event, the router continues to forward packets using the existing stale forwarding information.

Nonstop forwarding is used to notify peer routers to continue forwarding and receiving packets, even if the route processor (control plane) is not working or is in a switch-over state. Nonstop forwarding requires clean control plane and data plane separation and usually the forwarding information is distributed to the line cards.

This method of availability has both advantages and disadvantages. Nonstop forwarding continues to forward packets using the existing stale forwarding information during a failure. This may cause routing loops and black holes; surrounding routers must adhere to separate extension standards for each protocol. Each vendor must support protocol extensions for router interoperability.

Nonstop routing on 7210 SAS-R6 and 7210 SAS-R12

The Nonstop Routing (NSR) feature on 7210 SAS devices ensures that routing neighbors are unaware of a routing process fault. If a fault occurs, a reliable and deterministic activity switch to the inactive control complex occurs; the routing topology and reachability are not affected, even during routing updates. NSR achieves HA through parallelization by maintaining up-to-date routing state information, at all times, on the standby route processor. This is achieved independent of protocols or protocol extensions and provides a more robust solution than graceful restart protocols between network routers.

The NSR implementation on the 7210 SAS routers supports all routing protocols. It allows existing sessions (BGP, LDP, OSPF, and others) to be retained during a CFM or CPM switchover, including the support for MPLS signaling protocols. No change is visible to the peers.

Protocol extensions are not required. There are no interoperability issues and defining protocol extensions for each protocol is not required. Unlike nonstop forwarding and graceful restart, the forwarding information in NSR is always up to date, which eliminates possible black holes or forwarding loops.

Traditionally, addressing HA issues has been patched through nonstop forwarding solutions. The NSR implementation overcomes these limitations by delivering an intelligent, hitless failover solution. This enables a carrier-class foundation for transparent networks that is required to support business IP services backed by stringent SLAs. This level of HA support poses a major issue for conventional routers whose architectural design limits or prevents them from implementing NSR.

CPM switchover on 7210 SAS-R6 and 7210 SAS-R12

During a switchover, system control and routing protocol execution are transferred from the active to the standby CPM.

An automatic switchover may occur under the following conditions:

  • a fault condition that causes the active CPM to crash or reboot

  • the active CPM is declared down (not responding)

  • online removal of the active CPM

A manual switchover may occur under the following conditions:

  • To force a switchover from an active CPM to a standby, use the admin redundancy force-switchover command. You can also use the config system switchover-exec and admin redundancy force-switchover now CLI commands to configure a batch file that runs after a failover.

Temperature threshold alarm and fan speed

The following table lists the over-temperature thresholds for 7210 SAS devices.

Table 2. Over-temperature threshold for 7210 SAS devices

Device variants

Minimum temperature (in degrees centigrade)

Maximum temperature (in degrees centigrade)

7210 SAS-Mxp

0

76

7210 SAS-Mxp ETR

-10

80

7210 SAS-R6

-1

74

7210 SAS-R12

0

96

7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE

0

85

7210 SAS-T

0

58

7210 SAS-T ETR

-21

68

The 7210 SAS system software controls the fans by monitoring the internal temperature of the chassis. The software manages the fan speed to maintain the internal temperature within operational limits.

The 7210 SAS-R6 supports overheat protection reboot. This feature protects the IMM and CPM cards when the temperature exceeds system-defined temperature thresholds; these thresholds are not user-configurable. The software monitors the temperature of each card and if the temperature exceeds the threshold, the system raises an over-temperature critical event. The system reboots all overheated CPM cards and powers off all overheated IMM cards to reduce the heat generated, which consequently cools down the chassis. The system powers back on the IMM cards after the temperature is reduced. Operators are still required to take immediate action for an over-temperature critical event. See the 7210 SAS-R6 Chassis Installation Guide for more information about maintaining the operating temperature.

Note:

Nokia recommends that when planning their availability design, operators must consider CPM card reboot handling that is caused when the system temperature exceeds system-defined thresholds. Failure to build in network redundancy may result in network and service downtime.

Synchronization

This section describes the synchronization between the CPMs or CFMs.

Configuration and boot-env synchronization

Configuration and boot-env synchronization are supported in the admin>redundancy>synchronize and config>redundancy>synchronize contexts.

State database synchronization

If a new standby CPM or CFM is inserted into the system, it synchronizes with the active CPM or CFM upon a successful boot process.

If the standby CPM or CFM is rebooted, it synchronizes with the active CPM or CFM after a successful boot process.

When configuration or state changes occur, an incremental synchronization is conducted from the active CPM or CFM to the standby CPM or CFM.

If the synchronization fails, the standby CPM or CFM does not reboot automatically. Use the show redundancy synchronization command to display synchronization output information.

If the active and standby CPMs or CFMs are not synchronized for any reason, you can manually synchronize the standby CPM or CFM by rebooting the standby by issuing the admin reboot standby command on the active or the standby CPM or CFM.

Synchronization and redundancy

The 7210 SAS-R6 and 7210 SAS-R12, and the 7210 SAS-Sx/S 1/10GE configured in the standalone-VC mode support CPM redundancy. Redundancy methods facilitate system synchronization between the active and standby CPMs so they maintain identical operational parameters, which prevents inconsistencies in the event of a CPM failure.

When automatic system synchronization is enabled for an entity, save or delete file operations that are configured on the primary, secondary or tertiary choices on the active CPM file system are mirrored in the standby CPM file system.

Although software configurations and images can be copied or downloaded from remote locations, synchronization can only occur locally between compact flash drives (cf1: and cf2:).

Synchronization can occur:

  • automatically

    Automatic synchronization is disabled by default. To enable automatic synchronization, run the config>redundancy>synchronize command with the boot-env parameter or the config parameter.

    When the boot-env parameter is specified, the BOF, boot.ldr, configuration, and image files are automatically synchronized. When the config parameter is specified, only the configuration files are automatically synchronized.

    Automatic synchronization also occurs whenever the BOF is modified and when an admin>save command is entered with no filename specified.

  • manually

    To execute synchronization manually, run the admin>redundancy> synchronize command with the boot-env parameter or the config parameter.

    When the boot-env parameter is specified, the BOF, boot.ldr, configuration, and image files are synchronized. When the config parameter is specified, only the configuration files are synchronized.

The following output is an example of information displayed during a manual synchronization of configuration files.

A:ALA-12>admin>redundancy# synchronize config 
Syncing configuration......

Syncing configuration.....Completed.
A:ALA-12# 

Active and standby designations on 7210 SAS-R6 and 7210 SAS-R12

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.

The following output sample shows that the CPM installed in slot A is acting as the active CPM and the CPM installed in slot B is acting as the standby.

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#

The following console message is displayed if a CPM boots, detects an active CPM, and assumes the role of the standby CPM.

...
Slot A contains the Active CPM

This CPM (slot B) is the standby CPM.

Active and standby designations on 7210 SAS-Sx/S 1/10GE in standalone-VC mode

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.

The following output sample shows two nodes configured as CPM-IMM nodes with one becoming the active node and the other becoming the standby node.

*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 CPM B boots, it waits 60 seconds to detect an active CPM A. If CPM A does not respond after 60 seconds, CPM B assumes the role of the active node.

When the active CPM goes offline

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.

The following console message is displayed when the active CPM goes offline and the standby CPM assumes the active role:

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

Configuration guidelines for synchronization of active and standby CPM on 7210 SAS-R6 and 7210 SAS-R12

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.

Network synchronization

Note:

See the information in this section andsee the 7210 SAS OS Software Release Notes 11.0Rx for information about network synchronization options supported on each 7210 SAS platform.

This section describes the network synchronization capabilities available on7210 SAS platforms. These capabilities involve multiple approaches to network timing, including Synchronous Ethernet, PTP/1588v2, adaptive timing, and others. These features address barriers to entry as follows:

  • provide synchronization quality required by mobile networks, such as radio operations and circuit emulation services (CES) transport

  • augment and potentially replace the existing (SONET/SDH) timing infrastructure and deliver high quality network timing for time-sensitive wireline applications

Note:

Synchronous Ethernet and IEEE1588v2 PTP are not supported on virtual chassis (VCs).

Network synchronization is commonly distributed in a hierarchical PTP topology at the physical layer, as shown in the following figure.

Figure 1. Conventional network timing architecture (North American nomenclature)

The architecture shown in the preceding figure provides the following benefits:

  • It limits the need for high quality clocks at each network element and only requires that they reliably replicate input to remain traceable to its reference.

  • It uses reliable physical media to provide transport of the timing signal. It does not consume any bandwidth and requires limited additional processing.

The synchronization network is designed so a clock always receives timing from a clock of equal or higher stratum or quality level. This ensures that if an upstream clock has a fault condition (for example, loses its reference and enters a holdover or free-run state) and begins to drift in frequency, the downstream clock will be able to follow it. For greater reliability and robustness, most offices and nodes have at least two synchronization references that can be selected in priority order (such as primary and secondary).

Further levels of resiliency can be provided by designing a capability in the node clock that will operate within prescribed network performance specifications without any reference for a specified timeframe. A clock operating in this mode is said to hold the last known state over (or holdover) until the reference lock is once again achieved. Each level in the timing hierarchy is associated with minimum levels of network performance.

Each synchronization capable port can be independently configured to transmit data using the node reference timing. In addition, some TDM channels can use adaptive timing or loop timing.

Transmission of a reference clock through a chain of Ethernet equipment requires that all equipment supports Synchronous Ethernet. A single piece of equipment that is not capable of performing Synchronous Ethernet breaks the chain. Ethernet frames will still get through but downstream devices should not use the recovered line timing because it will not be traceable to an acceptable stratum source.

Central synchronization subsystem

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.

Figure 2. Logical model of synchronization reference selection on 7210 SAS

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.

Table 3. Revertive, non-revertive timing reference switching operation

Status of reference A

Status of reference B

Active reference non-revertive case

Active reference revertive case

OK

OK

A

A

Failed

OK

B

B

OK

OK

B

A

OK

Failed

A

A

OK

OK

A

A

Failed

Failed

holdover

holdover

OK

Failed

A

A

Failed

Failed

holdover

holdover

Failed

OK

B

B

Failed

Failed

holdover

holdover

OK

OK

A or B

A

Synchronization options available on 7210 SAS platforms

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.

Table 4. Synchronization options for 7210 SAS platforms
Synchronization options 7210 SAS platforms
T S 1/10GE R6 R12 Mxp1 Sx 1/10GE1 Sx 10/100GE1

SyncE with SSM (1GE and 10G/E fiber ports)

SyncE with fixed copper ports2

3

4

5

6

Adaptive Clock Recovery (ACR)

1588v2/PTP with port-based timestamps (both for frequency and time – also called PTP pure mode)

1588v2/PTP with port-based timestamps (time only with SyncE or BITS (if supported) used for frequency recovery – also called PTP hybrid mode)

7

PTP end-to-end (E2E) transparent clock

BITS

8

9

9

1pps and 10MHz interfaces

10

10

10

10

Synchronization Status Messages

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

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

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.

Synchronous Ethernet

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.

Note:
  • The use of Synchronous Ethernet as a candidate reference and for distribution of recovered reference is supported on all 7210 SAS platforms as described in this document, except those operating in standalone-VC mode.

  • Synchronous Ethernet using fiber Ethernet ports, including 10G and 100G (if available), is supported on all 7210 SAS platforms as described in this document, except those operating in standalone-VC mode.

  • Please ensure that the SFP or XFP or SFP+ parts used with the SFP, XFP, and SFP+ ports support Synchronous Ethernet.

  • Synchronous Ethernet is not supported on virtual chassis (VCs).

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.

Clock source quality level definitions

This section describes the clock source quality levels identified for tracking network timing flow in accordance with the network deployment options defined in Recommendation G.803 and G.781. The Option I network is developed on the original European SDH model; Option II network is a network developed on the North American SONET model.

In addition to the QL values received over SSM of an interface, the standards define the following additional codes for internal use:

  • QL INVx is generated internally by the system if and when an unallocated SSM value is received, where x represents the binary value of this SSM. Within the SR OS, these independent values are assigned as the single value QL-INVALID.

  • QL FAILED is generated internally by the system if and when the terminated network synchronization distribution trail is in the signal fail state.

The internal quality level of QL-UNKNOWN is used to differentiate from a received QL-STU code, but is equivalent for the purposes of QL selection.

The following table lists the synchronization message coding and source priorities for SSM values received on port.

Table 5. Synchronization message coding and source priorities

SSM value received on port

SDH interface

SyncE interface in SDH mode

SONET interface

SyncE interface in SONET mode

E1 interface

T1 interface (ESF)

Internal relative quality level

0010 (prc)

0001 (prs)

0010 (prc)

00000100 11111111 (prs)

1. Best quality

0000 (stu)

00001000 11111111 (stu)

2.

0111 (st2)

00001100 11111111 (ST2)

3.

0100 (ssua)

0100 (tnc)

0100 (ssua)

01111000 11111111 (TNC)

4.

1101 (st3e)

01111100 11111111 (ST3E)

5.

1000 (ssub)

1000 (ssub)

6.

1010 (st3/eec2)

00010000 11111111 (ST3)

7.

1011 (sec/eec1)

1011 (sec)

8. Lowest quality qualified in QL-enabled mode

1100 (smc)

00100010 11111111 (smc)

9.

00101000 11111111 (st4)

10.

1110 (pno)

01000000 11111111 (pno)

11.

1111 (dnu)

1111 (dus)

1111 (dnu)

00110000 11111111 (dus)

12.

Any other

Any other

Any other

N/A

13. QL_INVALID

14. QL_FAILED

15. QL_UNC

The following table lists the synchronization message coding and source priorities for SSM values transmitted by interface type.

Table 6. Synchronization message coding and source priorities

SSM values to be transmitted by interface of type

Internal relative quality level

SDH interface

SyncE interface in SDH mode

SONET interface

SyncE interface in SONET mode

E1 interface

T1 interface (ESF)

1. Best quality

0010 (prc)

0001 (PRS)

0010 (prc)

00000100 11111111 (PRS)

2.

0100 (ssua)

0000 (stu)

0100 (ssua)

00001000 11111111 (stu)

3.

0100 (ssua)

0111 (st2)

0100 (ssua)

00001100 11111111 (st2)

4.

0100 (ssua)

0100 (tnc)

0100 (ssua)

01111000 11111111 (tnc)

5.

1000 (ssub)

1101 (st3e)

1000 (ssub)

01111100 11111111 (st3e)

6.

1000 (ssub)

1010 (st3/eec2)

1000 (ssub)

00010000 11111111 (st3)

7.

1011 (sec/eec1)

1010 (st3/eec2)

1011 (sec)

00010000 11111111 (st3)

8. Lowest quality qualified in QL-enabled mode

1011 (sec/ eec1)

1100 (smc)

1011 (sec)

00100010 11111111 (smc)

9.

1111 (dnu)

1100 (smc)

1111 (dnu)

00100010 11111111 (smc)

10.

1111 (dnu)

1111 (dus)

1111 dnu

00101000 11111111 (st4)

11.

1111 (dnu)

1110 (pno)

1111 (dnu)

01000000 11111111 (pno)

12.

1111 (dnu)

1111 (dus)

1111 (dnu)

00110000 11111111 (dus)

13.

1111 (dnu)

1111 (dus)

1111 (dnu)

00110000 11111111 (dus)

14.

1111 (dnu)

1111 (dus)

1111 (dnu)

00110000 11111111 (dus)

15.

1011 (sec/eec1)

1010 (st3/eec2)

1011 (sec)

00010000 11111111 (st3)

IEEE 1588v2 PTP

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.

Figure 3. Peer clocks

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

Note:

PTP is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-Sx 10/100GE and 7210 SAS-Sx/S 1/10GE operating in standalone-VC mode. See Configuration guidelines and restrictions for PTP for a list of PTP profiles, and the configuration guidelines and restrictions.

Table 7. IP/UDP unicast and Ethernet multicast support

Platform

IP/UDP Unicast

Ethernet Multicast

7210 SAS-T

Yes

Yes

7210 SAS-Mxp

Yes

Yes

7210 SAS-Sx 1/10GE

Yes

Yes11

7210 SAS-S 1/10GE

No

No

7210 SAS-Sx 10/100GE12

No

Yes11

7210 SAS-R6

Yes

Yes13

7210 SAS-R12

Yes

Yes13

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.

Figure 4. Ethernet multicast ports
Note:

7210 SAS platforms do not support ordinary clock timeTransmitter configuration.

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)

Note:

The following caveats apply to G.8275.1 support. See sectionConfiguration guidelines and restrictions for PTP for configuration guidelines and restrictions.

  • PTP with Ethernet encapsulation is only supported with G.8275.1 profiles.

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

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.

Table 8. Local clock parameters when profile is set to ieee1588-2008

Parameter

Value

clockClass

248 – the 7210 SAS is configured as a boundary clock

255 – the 7210 SAS is configured as an ordinary clock timeReceiver

clockAccuracy

FE - unknown

offsetScaledLogVariance

FFFF – not computed

clockIdentity

Chassis MAC address following the guidelines of section 7.5.2.2.2 of IEEE 1588-2008

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.

Table 9. Local clock parameters when profile is set to itu-telecom-freq

Parameter

Value

clockClass

80-110 – value corresponding to the QL out of the central clock of the 7210 SAS as per Table 1/G.8265.1

255 – the 7210 SAS is configured as an ordinary clock timeReceiver

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.

Table 10. Local clock parameters when profile is set to g8275dot1-2014

Parameter

Value

clockClass

165 – the 7210 SAS is configured as a boundary clock and the boundary clock was previously locked to a grandmaster with clock class of 6

248 – the 7210 SAS is configured as a boundary clock

255 – the 7210 SAS is configured as an ordinary clock timeReceiver

clockAccuracy

FE – unknown

offsetScaledLogVariance

FFFF – not computed

clockIdentity

Chassis MAC address following the guidelines of section 7.5.2.2.2 of IEEE 1588-2008

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.

Note:

Contact a Nokia technical support representative for scaling information about specific unicast message limits related to PTP.

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.

Figure 5. Messaging sequence between the PTP timeReceiver clock and PTP timeTransmitter clocks

PTP clock synchronization

The IEEE 1588v2 standard synchronizes the frequency and time from a timeTransmitter clock to one or more timeReceiver clocks over a packet stream. This packet-based synchronization can be over IP/UDP unicast or Ethernet multicast.

As part of the basic synchronization timing computation, event messages are defined for synchronization messaging between the PTP timeReceiver clock and PTP timeTransmitter clock. A one-step or two-step synchronization operation can be used; the two-step operation requires a follow-up message after each synchronization message.

Note:

  • 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 only one-step timeTransmitter port operation.

  • All platforms can operate timeReceiver ports that receive PTP messages from a one-step or two-step timeTransmitter port.

During startup, the PTP timeReceiver clock receives synchronization messages from the PTP timeTransmitter clock before a network delay calculation is made. Before any delay calculation, the delay is assumed to be zero. A drift compensation is activated after a number of synchronization message intervals occur. The expected interval between the reception of synchronization messages is user-configurable.

The following figure shows the basic synchronization timing computation between the PTP timeReceiver clock and PTP best timeTransmitter; the offset of the timeReceiver clock is shown referenced to the best timeTransmitter signal during startup.

Figure 6. PTP timeReceiver clock and timeTransmitter clock synchronization timing computation

When the IEEE 1588v2 standard is used for distribution of a frequency reference, the timeReceiver calculates a message delay from the timeTransmitter to the timeReceiver based on the timestamps exchanged. A sequence of these calculated delays contains information about the relative frequencies of the timeTransmitter clock and timeReceiver clock, but also includes a noise component related to the PDV experienced across the network. The timeReceiver must filter the PDV effects to extract the relative frequency data and then adjust the timeReceiver frequency to align with the timeTransmitter frequency.

When the IEEE 1588v2 standard is used for distribution of time, the 7210 SAS calculates the offset between the 7210 SAS time base and the external timeTransmitter clock time base based on the four timestamps exchanged. The 7210 SAS determines the offset adjustment, and between these adjustments, it maintains the progression of time using the frequency from the central clock of the node. This allows time to be maintained using a Synchronous Ethernet input source even if the IEEE 1588v2 communications fail. When using IEEE 1588v2 for time distribution, the central clock should, at a minimum, have the PTP input reference enabled.

The following figure shows the logical model for using PTP/1588 for network synchronization.

Figure 7. Logical model for using PTP/1588 for network synchronization on 7210 SAS platforms

Performance considerations

Although IEEE 1588v2 can be used on a network that is not PTP-aware, the use of PTP-aware network elements (boundary clocks) within the packet switched network improves synchronization performance by reducing the impact of PDV between the grandmaster clock and the timeReceiver clock. In particular, when IEEE 1588v2 is used to distribute high-accuracy time, such as for mobile base station phase requirements, the network architecture requires the deployment of PTP awareness in every device between the grandmaster and the mobile base station timeReceiver.

In addition, performance is also improved by the removal of any PDV caused by internal queuing within the boundary clock or timeReceiver clock. This is accomplished with hardware that is capable of port-based timestamping, which detects and timestamps the IEEE 1588v2 packets at the Ethernet interface.

PTP end-to-end Transparent Clock

Note:

This feature is supported only on the 7210 SAS-Sx 1/10GE and 7210 SAS-Sx 10/100GE.

The 7210 SAS devices support PTP end-to-end (E2E) Transparent Clock (TC) functionality, which allows the node to update the PTP correction fields (CFs) for the residence time of the PTP message. See Synchronization options for 7210 SAS platforms for a list of platforms that support this functionality.

A CLI option is provided to enable the PTP port-based hardware timestamp on ports that receive and forward PTP messages. To enable the TC function, PTP must not be enabled on the node. When the timestamp option is enabled, the node identifies standards-based messages and updates the CF for PTP IP/UDP multicast and unicast messages, and for the PTP Ethernet multicast and unicast messages. The CF is updated for the residence time of the PTP message. Downstream PTP timeReceivers that receive the PTP message use the updated CF to measure the delay between the timeTransmitter and themselves.

You can enable the TC option by running the configure>port>ethernet>ptp-hw-timestamp command on ports (both ingress and egress) on which residence time in the PTP message must be updated when the message is in transit through the node. You can disable the residence time update by running the no form of the command on both ingress and egress ports, as required. No additional CLI commands are required to enable the PTP TC option.

Nokia recommends the following operational guidelines and examples for enabling and using the PTP TC feature:

  • Assume port 1/1/10 is connected to a PTP timeTransmitter clock (using a port, a SAP, or an IES IP interface) and 1/1/15 is connected to a PTP timeReceiver clock (using a port, a SAP, or an IES IP interface).

    To enable PTP TC in this scenario, you must enable the ptp-hw-timestamp command on both ports. To disable PTP TC, run the no form of the command on both ports.

  • Assume port 1/1/10 is connected to a PTP timeTransmitter clock (using a port, a SAP, or an IES IP interface) and ports 1/1/15 and 1/1/16 have PTP timeReceivers (using a port, a SAP, or an IES IP interface), with a PTP session to the PTP timeTransmitter clock that is connected on port 1/1/10.

    To enable PTP TC, the ptp-hw-timestamp command must be enabled on all three ports.

    In this scenario, it is not possible to disable PTP TC only towards the timeReceiver connected on port 1/1/15. The functionality must be disabled on all three ports.

    Additionally, note that the PTP messages coming in on port 1/1/10 are not forwarded out of any ports other than 1/1/15 and 1/1/16, when the ptp-hw-timestamp command is enabled on port 1/1/10. Nokia recommends that when a set of PTP ports are enabled for ptp-hw-timestamp, the operator must ensure that PTP messages are forwarded to only the specific set of ports where the TC option is enabled, and not to other ports. Forwarding PTP messages to other ports that do not belong to the specific set may result in incorrect updates.

  • You can enable PTP TC for a set of SAPs and also transparently forward PTP packets on other SAPs, while both SAPs share a common uplink to forward PTP messages. To implement this scenario, use MPLS tunnels with network ports as the uplinks. Nokia recommends the following configuration.

    • PTP hardware port-based timestamping must be disabled on the access ports where SAPs are configured. These access ports are typically used to connect to either PTP timeTransmitter or PTP timeReceivers that need to establish and exchange PTP messages transparently.

    • PTP hardware port-based timestamping must be enabled on the access ports where SAPs are configured and the TC function is required. These access ports are typically used to connect to either the PTP timeTransmitter or PTP timeReceivers.

    • PTP hardware port-based timestamping must be enabled on the network ports where the MPLS tunnels originate and terminate. In this case, the PTP TC function updates only the PTP messages that are not MPLS encapsulated.

    • See PTP message transparent forwarding for additional support information.

PTP message transparent forwarding

On bootup, port-based hardware timestamping is enabled by default on all 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, and the node processes both transit packets and locally destined PTP packets. Use the ptp-hw-timestamp command to disable port-based hardware timestamping in the following cases:

  • to allow the node to transparently forward PTP packets when MPLS uplinks are used

  • when PTP is enabled and used to synchronize and time the node (that is, PTP messages are originated and terminated by the node acting as a PTP OC-timeReceiver or BC)

  • on ports that receive PTP packets that will be forwarded transparently

When PTP port-based hardware timestamp is disabled, the node does not update the correction field in PTP messages. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about the ptp-hw-timestamping command.

For example, to enable transparent forwarding of PTP packets over MPLS tunnels, when access ports with SAPs are used to connect the PTP timeTransmitter or PTP timeReceivers, the ptp-hw-timestamp command can be used to disable PTP port-based hardware timestamping on these access ports.

Note:

The ptp-hw-timestamp command is only supported 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. Port-based hardware timestamping can be used for transparent PTP packet forwarding if PTP is enabled and used to time the node (that is, PTP messages are originated and terminated by the node acting as a PTP OC-timeReceiver or BC).

The following guidelines must be considered for transparent PTP packet forwarding:

  • By default, PTP port-based hardware timestamping is enabled on all ports at bootup. To allow transparent PTP packet forwarding, the feature must be disabled using the configure>port>no ptp-hw-timestamp command.

  • On 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, if the ptp-hw-timestamp command is enabled by executing the command on a set of ports, the node processes PTP packets that transit those ports to update the correction field for the packet residence time in the node. This allows accurate computation by PTP time and frequency recovery algorithms on PTP timeReceiver clocks that are connected to those ports.

  • The command to enable PTP hardware timestamps for packets transiting the node should be configured on both the ingress and egress port where PTP packets are expected to be received and sent from (and where they need to be processed to update correction time). Configuring the PTP hardware timestamp command on only the ingress port or egress port is not recommended because this will result in incorrect updates to the correction field.

  • For 7210 SAS-R6 and 7210 SAS-R12 platforms with IMM-b (IMMv2) and IMM-c cards, and for the 7210 SAS-Mxp and 7210 SAS-Sx 1/10GE, to enable transparent forwarding of PTP packets over MPLS tunnels, PTP hardware port-based timestamping must be disabled on the access ports where SAPs are configured. These access ports are used to connect to either PTP timeTransmitter or PTP timeReceivers that need to establish and exchange PTP messages transparently. PTP hardware port-based timestamping does not need to be disabled on the network ports where the MPLS tunnels originate and terminate. This means that these network ports can be used for PTP packet exchange when the node is a PTP boundary clock or ordinary clock timeReceiver. If the requirement is to forward PTP packets transparently when MPLS uplinks are not used or when a hybrid port with a SAP is used, PTP hardware port-based timestamping must be disabled on the access port and hybrid port.

  • On the 7210 SAS-Mxp and 7210 SAS-Sx 1/10GE, PTP messages for the G.8265.1 and IEEE 1588v2 profiles are transparently forwarded only for a VPRN service on which hardware timestamping is enabled on the access port. This restriction only applies to PTP packets that are using IP/UDP unicast encapsulation.

  • To enable transparent forwarding of PTP packets over MPLS tunnels on the 7210 SAS-T, you must disable hardware timestamping on access ports where SAPs are configured, and on the MPLS tunnel originating and terminating network ports. Consequently, these network ports cannot be used for PTP packet exchange when the node is a PTP boundary clock or ordinary clock timeReceiver.

    To use the node as a PTP boundary clock or ordinary clock timeReceiver, you must use separate ports. In other words, a different access port, network port, or hybrid port must be used for PTP message exchange when this node is configured to be a PTP boundary clock or ordinary clock timeReceiver, and it cannot be any of the ports (either ingress or egress ports) on which PTP packets are forwarded transparently.

PTP capabilities

PTP messages are supported through IPv4 unicast with a fixed IP header size. The following table describes the supported message rates for timeReceiver and timeTransmitter states. The ordinary clock can only be used in the timeReceiver state. The boundary clock can be in both of these states.

Table 11. Support message rates for timeReceiver and timeTransmitter clock states

Support message

timeReceiver clock

timeTransmitter clock

Request rate

Grant rate

Min

Max

Announce

1 packet every 2 seconds

1 packet every 2 seconds

1 packet every 2 seconds

Sync

User-configurable with an option to configure 8/16/32/64 packets/second

8 packets/second

16 or 64 packets/second14

Delay_Resp

User-configurable with an option to configure 8/16/32/64 packets/second

8 packets/second

16 or 64 packets/second14

Duration

300 seconds

1 second

1000 seconds

State and statistics data for each timeTransmitter clock are available to assist in the detection of failures or unusual situations.

PTP ordinary timeReceiver clock for frequency

Traditionally, only clock frequency is required to ensure smooth transmission in a synchronous network. The PTP ordinary clock with timeReceiver capability on the 7210 SAS provides another option to reference a Stratum-1 traceable clock across a packet switched network. The recovered clock can be referenced by the internal SSU and distributed to all slots and ports.

The following figure shows a PTP ordinary timeReceiver clock network configuration.

Figure 8. timeReceiver clock

PTP boundary clock for frequency and time

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.

Figure 9. Boundary clock

1PPS and 10MHz output interface

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.

Note:

1pps and 10MHz signals are available only when PTP is enabled.

Configuration guidelines and restrictions for PTP

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.

Configuration example to use PTP and SyncE references

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.

The following configuration example shows the simultaneous use of PTP and SyncE references:

*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
----------------------------------------------

Management of 1830 VWM

Note:

This feature is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T.

The 7210 SAS supports the use and management of the 1830 VWM CWDM and 1830 VWM DWDM clip-on device. 1830 VWM is a family of cost-optimized managed WDM passive devices, which is add-on shelf/NE and provides CWDM/DWDM extension to devices that do not have in-built CWDM/DWDM capabilities. The 1830 VWM can act as a Fixed Channel Optical Add-Drop Multiplexer (FOADM) or multiplexer/demultiplexer unit. It allows operators to use the existing fiber (or use less fiber) and increase the bandwidth capacity available for carrying service traffic.

For more information about 1830 VWM, see 1830 VWM product user guides.

The 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T manage the 1830 VWM device using the Optical Management Console (OMC) port.

Introduction

The 1830 VWM device can be used in point-to-point or ring deployments to multiplex multiple CWDM/DWDM channels over a single fiber. Either the existing fiber is reused or a single fiber is used to meet the increasing demand for service bandwidth. Up to 8 fixed CWDM channels are multiplexed over a single fiber using this unit.

The following figure shows 5 CWDM channels that are multiplexed over a single fiber.

Figure 10. Optical ring with 7210 SAS and 1830 VWM passive optical unit

There are two types of ring locations. One is a channel termination location, with the 1830 PSS-32 that optically terminates all the channels using either the 4-channel or the 8-channel termination module. The second location is the intermediate OADM sites with the 7210 SAS. These sites use the CWDM passive units to add or drop a channel in both directions (east and west), for the node to process traffic. Additionally, these sites provide express lanes for all other channels (that is, those not processed locally by the node). The 1830 VWM provides an option to add or drop up to 1, 2, 4 channels of fixed wavelength for local processing by the node.

Feature description

The 1830 VWM clip-on device can be connected to the 7210 SAS node (the master shelf) using the USB interface or the OMC interface, depending on the interface supported by the 7210 SAS platform. Each of these clip-on devices is identified using the shelf ID, which is set on the rotary dial provided on the device.

To assist inventory management, the operator must use the configure>system>vwm-shelf vwm-shelf-id vwm-type vwm-type create CLI command to configure the vwm-shelf-id of the clip-on device attached to the 7210 SAS node. The vwm-shelf-id must match the shelf ID that is set on the rotary dial of the clip-on device. 7210 SAS devices use the configured vwm-shelf-id to communicate with the clip-on device. If the shelf IDs do not match, the 7210 SAS cannot communicate with the device and does not provide any information about the device. The 7210 SAS cannot detect a mismatch between the configured vwm-shelf-id and the shelf ID set on the rotary dial.

Depending on the type of supported interface, USB or OMC, the 7210 SAS node can manage only a fixed number of 1830 VWM devices. The software prevents attempts to configure more 1830 VWM devices than can be supported by the interface in use. Use the show command supported by the 7210 SAS devices to display the shelf inventory and alarm status information provided by the clip-on device.

In addition to inventory management, 7210 SAS supports provisioning of cards inserted into the slots available on the 1830 VWM devices. Before the card can be managed by the 7210 SAS, the user must provision the card and card type (also known as module type). The 7210 SAS detects and reports provisioning mismatches for the card. It also detects and reports insertion and removal of the card/module from the slot on the 1830 VWM device.

The 1830 DWDM supports active and passive units. The first 1830 DWDM device that is connected to a 7210 SAS node using the OMC port or the USB port must be equipped with active DWDM controllers; passive DWDM controllers can be used in the other chassis connected to the first device in a stacked configuration. In other words, the first 1830 DWDM device that is connected to the OMC port or the USB port of the 7210 SAS node must not be a passive 1830 DWDM device, but subsequent chassis in the stacked configuration can be equipped with passive DWDM controllers. See the 1830 VWM User Guide for information about making the decision to equip active or passive DWDM controllers on the other chassis in the stacked configuration.

Note:

The 7210 SAS also auto detects the device type when any supported device is connected to the USB interface. Only approved USB mass storage devices and optical clip-on devices plugged in to the USB port are recognized as valid devices. Use of unsupported devices results in the generation of an error log. A shelf created by the user will be operationally down when an unrecognized device is plugged into the USB port. The user can interchange the device connected to the USB port without requiring a reboot. For example, when the 7210 SAS is operating with a clip-on device you can pull out the clip-on device and plug-in a USB mass-storage device to copy image files or other files, and then plug back a clip-on device.

1830 CWDM shelf layout and description

Note:

The 1830 CWDM shelf shown in 1830 CWDM shelf layout is an example. For definitive information about the 1830 CWDM device and support, see the 1830 CWDM product manuals.

The following figure shows an example of the 1830 CWDM passive device.

Figure 11. 1830 CWDM shelf layout

In the preceding figure, Slot 1 is dedicated to the controller card. The controller card, which is named using the acronym EC-CW for the 1830 CWDM device, does not require explicit provisioning. The card type is automatically provisioned when the user configures the 1830 VWM shelf type.

If the controller card is not present in Slot 1 of the shelf, the 1830 CWDM device operates as a passive filter and is not managed by the 7210 SAS. The 7210 SAS provides inventory and equipment management capability only when the controller card is present in the shelf and connected to the 7210 SAS.

Slot 2 and Slot 3 shown in the preceding figure can be equipped with supported CWDM filter cards. The user must provision the cards that populate the slots. The 7210 SAS software checks to ensure a match between the equipped and provisioned card type; an event is logged if a mismatch is detected.

1830 DWDM shelf layout and description

The following figure shows the 1830 DWDM shelf and the entities that can be managed by 7210 SAS.

Figure 12. 1830 DWDM shelf layout

The following information applies to the management of the 1830 DWDM shown in the preceding figure:

  • Slot 1 and Slot 2 host the DWDM Power and Controller modules (either EC-DW or EC-DWA). These slots host the Equipment Controller; power is provided by the Service NE (using EC-DW unit) or the TRU (using EC-DWA unit) in accordance with the system configuration and the Equipment Controller used. A rotary switch located on the top side of the Equipment Controller is used to set the SHELF_ID. In a stacked configuration, each Shelf_ID must be uniquely set. The Shelf_ID must be identical for the active and standby controllers in a shelf.

  • Slot 1 and Slot 2 are not directly provisioned by the user in the 7210 SAS. The user must provision and configure the vwm-type managed by the 7210 SAS. The vwm-type can be provisioned as ec-cw, ec-dw, or ec-dwa, indicating that the shelf is a CWDM passive shelf or a DWDM passive shelf or a DWDM active shelf.

  • The first 1830 DWDM device that is connected to the OMC port or the USB port of the 7210 SAS node must be equipped with the active DWDM controllers; it must not be a passive 1830 DWDM device. However, subsequent chassis connected to the first 1830 DWDM device in a stacked configuration can be equipped with passive DWDM controllers.

  • Slot 3 and Slot 4 are capable of hosting DWDM filters (MUX/Demux), optical amplifiers, and Bulk Power Management (BPM) module. These slots must be explicitly provisioned on the 7210 SAS to allow management by the 7210 SAS. The 7210 SAS can manage the following cards:

    • all DWDM filter (remote and manual filter and all of 2-channel, 4-channel and 8-channel)

    • fan module

    • BPM module (which allows for the aggregation of 44 DWDM channels using SFD44 unit) is not supported

  • The 7210 SAS host tracks the following events related to the modules in Slot 3 and Slot 4:

    • line card/module removal and insertion

    • provisioning mismatch, if the provisioned line card does not match the equipped line card

    • LoS alarm reported by the card/module for remote filter. The LoS alarm is cleared by the ec-dw/ec-dwa based on the threshold configured VOA.

    • monitoring power levels for remote filter is not supported and configuration of power thresholds for automatic power monitoring feature supported by the remote filter units is not allowed

    • 1830 DWDM fan module insertion and removal

  • Slot 5 hosts the fans or the Inventory Extension Module (IN/MOD). If the 7210 SAS is managing the 1830 device, provisioning Slot 5 is not supported. As a result, only the fan module can be equipped in the slot; IN/MOD is not supported.

1830 VWM configuration guidelines and restrictions

The 7210 SAS manages the 1830 VWM CWDM/DWDM clip-on device, and inventory, and displays information about the clip-on device including part numbers, clip-on type, manufacturing dates, firmware revision, and status of alarms. The 7210 SAS also supports provisioning of modules that can be inserted into the available slots on the 1830 device. The following are the configuration guidelines and restrictions that apply to the 1830 VWM:

  • The shelf-ID on the rotary dial must be set to a numeric value between 1 to 7. Digits higher than 7 are not supported by 7210 SAS devices.

  • The 1830 VWM clip-on device is connected to a master-shelf (for example, a 7210 SAS device). Each clip-on device is identified using the shelf ID set on the rotary dial provided on the device. To aid inventory management, the user must configure the vwm-shelf-id of the clip-on device attached to the USB interface or the OMC interface. The vwm-shelf-id must match the shelf ID that is set using the rotary dial on the clip-on device. The 7210 SAS uses the configured vwm-shelf-id to communicate with the clip-on device. If the two shelf IDs do not match, the 7210 SAS cannot interact with other devices and is unable to provide information about the device. The 7210 SAS cannot detect a mismatch between the configured vwm-shelf-id and the shelf ID set on the rotary dial.

  • The 7210 SAS provides a show command to display the alarm status information communicated by the clip-on device.

  • The 7210 SAS only recognizes approved USB mass storage and optical clip-on devices need as valid devices when plugged in the USB port. All other devices are treated as unsupported and cause the 7210 SAS to generate an error log. A shelf created by the user is operationally down when an unrecognized device is plugged into the USB port.

  • OMC ports must be used for 1830 DWDM device management on 7210 SAS-T and 7210 SAS-Mxp. USB ports are not supported on these platforms.

  • Management of the 1830 DWDM device is not supported on the 7210 SAS-R6 and 7210 SAS-R12.

  • Only a single 1830 CWDM or DWDM device can be managed using the USB interface.

  • The management capabilities available through USB and OMC port are similar.

  • The first 1830 DWDM device that is connected to the OMC port or the USB port of the 7210 SAS node must be equipped with active DWDM controllers; it must not be a passive 1830 DWDM device. However, subsequent chassis connected to the first 1830 DWDM device in a stacked configuration are allowed to be equipped with passive DWDM controllers. For more information about stacking configuration, see the 1830 VWM product manuals.

  • The number of DWDM or CWDM devices that are supported in a stacked configuration managed by the 7210 SAS is limited. Please contact your Nokia representative for information about the number of units supported.

  • In a stacked or cascaded configuration, all 1830 VWM units connected to the 7210 SAS must be of a similar type, either ec-cw or ec-dw/ec-dwa. A mix of CWDM and DWDM types is not supported.

Note:

The 1830 VWM allows for a mix of passive DWDM and active DWDM devices in a stacked configuration; the configuration is supported on all 7210 SAS platforms.

1830 VWM LED functionality

LED functionality for 7210 SAS and 1830 VWM (CWDM) and LED functionality for 7210 SAS and 1830 VWM (DWDM) describe the LED functionality of the device.

Table 12. LED functionality for 7210 SAS and 1830 VWM (CWDM)

Events

7210 SAS major alarm LED

Optical shelf controller LED

Optical shelf line card LED

Shelf admin up and shelf is physically connected to 7210 SAS

The shelf becomes operational up by default

No color

Green

Amber/green based on whether line card provisioned correctly or not

Shelf is operationally up

No color

Green

Amber/green based on whether card-type provisioned correctly or not

Line card admin up and operational down when card-type not provisioned correctly (that is, mismatch between provisioned and equipped type)

Red

Green

Amber for that line card LED

Line card admin up and operational up when card-type correctly provisioned

No color

Green

Green for that line card LED

Line card removed

Amber LED glows

Green

No LED glows (line card is removed)

Line card inserted back

No color

Green

LED turns to green

Table 13. LED functionality for 7210 SAS and 1830 VWM (DWDM)

Events

7210 SAS major alarm LED

Optical shelf controller LED

Optical shelf line card LED

Shelf admin up and shelf is physically connected to 7210 SAS. The shelf becomes operational up by default

No color

Green

Amber/green based on whether line card provisioned correctly or not

Shelf is operationally up

No color

Green

Amber/green based on whether card-type provisioned correctly or not

Line card admin up and operational down when card-type not provisioned correctly (that is, mismatch between provisioned and equipped type)

Amber

Green

Amber for that line card LED

Line card admin up and operational up when card-type correctly provisioned

No color

Green

Green for that line card LED

Line card removed

Amber LED glows

Green

No LED glows (line card is removed)

Line card inserted back

No color

Green

LED turns to green

Link Layer Discovery Protocol (LLDP)

The IEEE 802.1ab Link Layer Discovery Protocol (LLDP) is a unidirectional protocol that uses the MAC layer to transmit specific information about the capabilities and status of the local device. The LLDP can send as well as receive information from a remote device stored in the related MIB (or MIBs).

The LLDP does not contain a mechanism to solicit information received from other LLDP agents or to confirm the receipt of information. However, LLDP provides the flexibility to enable a transmitter and receiver separately, and the following LLDP agent configurations are allowed:

  • only transmit information

  • only receive information

  • transmit and receive information

The information fields in each LLDP frame are contained in an LLDP Data Unit (LLDPDU) as a sequence of variable length information elements. Each information element includes Type, Length, and Value fields (TLVs).

  • Type indicates the nature of information being transmitted.

  • Length indicates the length of the information string in octets.

  • Value is the actual information that is transmitted. (For example, a binary bit map or an alphanumeric string that can contain one or more fields).

Each LLDPDU contains four mandatory TLVs and optional TLVs selected by the Network Management. The following is the format of an LLDPDU:

  • Chassis ID TLV

  • Port ID TLV

  • Time To Live (TTL) TLV

  • zero or more optional TLVs, depending on the maximum size of the LLDPDU allowed

  • End of LLDPDU TLV

A concatenated string formed by the Chassis ID TLV and the Port ID TLV is used by a recipient to identify an LLDP port or agent. The combination of the Port ID and Chassis ID TLVs remains unchanged until the port or agent is operational.

The TTL field of a Time-To-Live TLV can be a zero or non-zero value. A zero TTL field value notifies the receiving LLDP agent to immediately discard all information related to sending LLDP agent. A non-zero TTL field value indicates the time duration for which the receiving LLDP agent should retain the information of the sending LLDP agent. The receiving LLDP agent discards all information related to the sending LLDP agent after the time interval indicated in the TTL field is complete.

Note:

A TTL zero value is used to signal that the sending LLDP port has initiated a port shutdown procedure.

The End Of LLDPDU TLV indicates the end of the LLDPDU.

The following information is included in the protocol as defined by the IEEE 802.1ab standard:

  • Connectivity and management information about the local station to adjacent stations on the same IEEE 802 LAN is advertised.

  • Network management information from adjacent stations on the same IEEE 802 LAN is received.

  • It operates with all IEEE 802 access protocols and network media.

  • Network management information schema and object definitions suitable for storing connection information about adjacent stations is established.

  • It supports compatibility with a number of MIBs.

System resource allocation

This section describes system resource allocation including the allocation of TCAM resources, configuration guidelines and examples.

Allocation of ingress internal TCAM resources

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.

Note:

The order in which the command appears in the configuration file is important.

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.

Allocation of egress internal TCAM resources

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.

Note:

The commands in the config>system>resource-profile context, which require a reboot to take effect, are read and implemented by the system only during bootup. These commands do not take effect if the exec command is used to run the configuration file.

System resource allocation examples

This section provides system resource allocation examples.

1

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

In the preceding CLI example, the system performs the following actions:

  • 3 chunks are allocated for use by the SAP ingress ACL entries.

  • 1 chunk is allocated for use by SAP ingress ACL entries that use ipv4-criteria. The system fails the configuration when the number of ACL entries that use ipv4-criteria exceeds the configured limit (that is, the system does not allocate in excess of the configured limit of 1 chunk).

  • A chunk is allocated for use by SAP ingress ACL entries that use mac-criteria. After the max keyword is specified, the system allocates 1 chunk for use when an ingress ACL policy (with mac-criteria entries defined) is associated with a SAP. The system can allocate up to 2 chunks because the max keyword is used. More chunks are allocated when the user configures a SAP that uses mac-criteria and all entries in the allocated chunks are used up. The system fails the configuration if the number of ACL entries with mac-criteria exceeds the limit of 2 chunks allocated to SAP ingress ACL match (that is, the system does not allocate in excess of the configured limit of 3 chunks; up to 2 chunks of the configured 3 chunk limit are allocated to mac-criteria and 1 chunk is allocated to ipv4-criteria).

  • The system fails a user attempt to use SAP ingress ACLs with IPv6 match criteria (and other combinations listed in the preceding list items), because the user has disabled these criteria.

2

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

In the preceding CLI example, the system performs the following actions:

  • 3 chunks are allocated for use by the SAP ingress ACL entries. These resources are available for use with mac-criteria, ipv4-criteria and ipv6-64-bit match criteria.

  • 1 chunk is allocated for use by SAP ingress ACL entries that use ipv4-criteria. The system fails the configuration if the number of ACL entries using ipv4-criteria exceeds the configured limit (that is, the system does not allocate more than the configured limit of 1 chunk).

  • 1 chunk is allocated for use by SAP ingress ACL entries that use mac-criteria when the user associates an ingress ACL policy (with mac-criteria entries defined) with a SAP. Because the max keyword is used, the system can allocate more chunks, if a chunk is available for use.

    In this example, (assuming a SAP with an ingress ACL policy that uses ipv6-64-bit criteria is configured), as no additional chunks are available, mac-criteria cannot allocate more than 1 chunk (even if the max keyword is specified). The system fails the configuration if the number of ACL entries with mac-criteria exceeds the limit of 1 chunk allocated to SAP ingress ACL mac-criteria (that is, the system does not allocate more than the configured limit of 3 chunks = 1 for mac-criteria + for ipv4-criteria + 1 for ipv6-criteria).

  • A chunk is allocated for use by SAP ingress ACL entries that use ipv6-64-bit criteria when the user associates an ingress ACL policy (with ipv6-64-bit-criteria entries defined) with a SAP. Because the max keyword is specified, the system can allocate more chunks, if a chunk is available for use.

    In this example, as there are no more chunks available, ipv6-64-bit criteria cannot allocate more than 1 chunk (even if the max keyword is specified). The system fails the configuration when the number of ACL entries with ipv6-64-bit criteria exceeds the limit of one chunk allocated to SAP ingress ACL match (that is, the system does not allocate more than the configured limit of 3 chunks = 1 for mac-criteria + 1 for ipv4-criteria + 1 for ipv6-64-bit criteria).

  • The system fails any attempt to use SAP ingress ACLs with ipv6-128 bit match criteria (and the other combinations listed above), because the user has disabled these criteria.

In Example: 2, the user can run no ipv4-match-enable command to disable the use of ipv4-criteria. The system checks for SAPs that use ipv4-criteria and if found, fails the command; otherwise, the chunk freed for use with either mac-criteria or ipv6-64-bit criteria. The entire chunk is allocated to mac-criteria if the first SAP that needs resources requests for mac-criteria and no entries in the chunk are already allocated to mac-criteria, which leaves no resources for use by ipv6-64-bit criteria. In the same way, the entire chunk is allocated to ipv6-64-bit criteria, if the first SAP that needs resources requests for ipv6-64-bit criteria and no entries in the chunk are already allocated to ipv6-64-bit criteria, which leaves no resources for use by mac-criteria.

7210 SAS-R6 and 7210 SAS-R12 configuration guidelines for system resource profile

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.

System configuration process overview

The following figure shows the process to provision basic system parameters.

Figure 13. System configuration and implementation flow

Configuration notes

This section describes system configuration caveats.

To access the CLI, ensure that the 7210 SAS device is properly initialized and the boot loader and BOFs have successfully executed.

Configuring system management with CLI

This section provides information about configuring system management features with CLI.

Saving configurations

Whenever configuration changes are made, the modified configuration must be saved so the changes are not lost when the system is rebooted. The system uses the configuration and image files, as well as other operational parameters necessary for system initialization, according to the locations specified in the boot option file (BOF) parameters. See Boot options for more information about boot option files.

Configuration files are saved by executing implicit or explicit command syntax:

  • An explicit save writes the configuration to the location specified in the save command syntax using the file-url option.

  • An implicit save writes the configuration to the file specified in the primary configuration location.

    If the file-url option is not specified in the save command syntax, the system attempts to save the current configuration to the current BOF primary configuration source. If the primary configuration source (path and/or filename) has changed since the last boot, the new configuration source is used.

Use the detail option of the save command to save both default and non-default configuration parameters.

The index option ensures that the system preserves system indexes when a save command is executed, regardless of the persistent status in the BOF. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indexes are preserved between reboots, including the interface index, LSP IDs, and path IDs. This reduces resynchronizations of the Network Management System (NMS) with the affected network element.

If the save attempt fails at the destination, an error occurs and is logged. The system does not try to save the file to the secondary or tertiary configuration sources unless the path and filename are explicitly named with the save command.

Basic system configuration

This section provides information to configure system parameters and provides configuration examples of common configuration tasks. The minimal system parameters that should be configured are System information parameters, Coordinates, and System time elements.

Basic system configuration

A:ALA-12>config>system# info
#------------------------------------------
        name "ALA-12"
        coordinates "Unknown"
        snmp
        security
            snmp
                community "private" rwa version both
            exit
        exit
        time
            ntp
                server 192.168.15.221 
                no shutdown
            exit
            sntp
                shutdown
            exit
            zone GMT
        exit
----------------------------------------------
A:ALA-12>config>system#

Common configuration tasks

This section provides an overview of the CLI commands used to configure the following system parameters: System information, Coordinates, System time elements, and System administration parameters.

System information

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.

System information parameters

This section describes the system information parameters.

Name

Use the system name command to configure a name for the device. The name is used in the prompt string. Only one system name can be configured. If multiple system names are configured, the last one encountered overwrites the previous entry.

Use the following CLI syntax to configure the system name.

config>system
        name <system-name>
Command usage
config>system# name ALA-12
System name configuration
sysName@domain>config>system# info
#------------------------------------------
echo "System Configuration "
#------------------------------------------
        name "ALA-12"
. . .
        exit
----------------------------------------------
sysName@domain>config>system#
Contact

Use the contact command to specify the name of a system administrator, IT staff member, or other administrative entity.

Use the following syntax to specify the contact name.

config>system
        contact <contact-name>
Command usage to specify the contact name
config>system# contact ‟Fred Information Technology”
Location

Use the location command to specify the system location of the device. For example, enter the city, building address, floor, and room number where the router is located.

Use the following CLI syntax to configure the location.

config>system
        location <location>

The following example shows the command usage to configure the location of the device.

config>system# location ‟Bldg.1-floor 2-Room 201”
CLLI code

The Common Language Location code (CLLI code) is an 11-character standardized geographic identifier that is used to uniquely identify the geographic location of a router.

Use the following CLI command syntax to define the CLLI code.

config>systemclli-code <clli-code>

The following example shows the command usage to define the CLLI code.

Example:
config>system# clli-code abcdefg1234

Coordinates

Use the optional coordinates command to specify the GPS location of the device. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

Use the following CLI syntax to configure the location.

config>system
        coordinates coordinates
Command usage to configure the location
config>system# coordinates "N 45 58 23, W 34 56 12"
Configuration output of general system commands
sysName@domain>config>system# 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"

. . .
        exit
----------------------------------------------
A:ALA-12>config>system#

System time elements

This section describes system time elements.

The system clock maintains time according to Coordinated Universal Time (UTC). Configure information time zone and summer time (daylight savings time) parameters to correctly display time according to the local time zone.

Zone

The zone command sets the time zone and/or time zone offset for the device. The 7210 SAS OS supports system-defined and user-defined time zones.

Use the following CLI syntax to set the time zone.

config>system>time
        zone std-zone-name|non-std-zone-name [hh [:mm]]
Command usage to set the time zone
config>system>time#
    config>system>time# zone GMT
Zone output
A:ALA-12>config>system>time# info
----------------------------------------------
ntp
                server 192.168.15.221 
                no shutdown
exit
sntp
                shutdown
exit
zone UTC 
----------------------------------------------
A:ALA-12>config>system>time#

The following table describes the system-defined time zones.

Table 14. System-defined time zones

Acronym

Time zone name

UTC offset

Europe

GMT

Greenwich Mean Time

UTC

WET

Western Europe Time

UTC

WEST

Western Europe Summer Time

UTC +1 hour

CET

Central Europe Time

UTC +1 hour

CEST

Central Europe Summer Time

UTC +2 hours

EET

Eastern Europe Time

UTC +2 hours

EEST

Eastern Europe Summer Time

UTC +3 hours

MSK

Moscow Time

UTC +3 hours

MSD

Moscow Summer Time

UTC +4 hours

US and Canada

AST

Atlantic Standard Time

UTC -4 hours

ADT

Atlantic Daylight Time

UTC -3 hours

EST

Eastern Standard Time

UTC -5 hours

EDT

Eastern Daylight Saving Time

UTC -4 hours

CST

Central Standard Time

UTC -6 hours

CDT

Central Daylight Saving Time

UTC -5 hours

MST

Mountain Standard Time

UTC -7 hours

MDT

Mountain Daylight Saving Time

UTC -6 hours

PST

Pacific Standard Time

UTC -8 hours

PDT

Pacific Daylight Saving Time

UTC -7 hours

HST

Hawaiian Standard Time

UTC -10 hours

AKST

Alaska Standard Time

UTC -9 hours

AKDT

Alaska Standard Daylight Saving Time

UTC -8 hours

Australia and New Zealand

AWST

Western Standard Time (for example, Perth)

UTC +8 hours

ACST

Central Standard Time (for example, Darwin)

UTC +9.5 hours

AEST

Eastern Standard/Summer Time (for example, Canberra)

UTC +10 hours

NZT

New Zealand Standard Time

UTC +12 hours

NZDT

New Zealand Daylight Saving Time

UTC +13 hours

Summer time conditions

The config>system>time>dst-zone context configures the start and end dates and offset for summer time or daylight savings time to override system defaults or for user-defined time zones.

When configured, the time is adjusted by adding the configured offset when summer time starts and subtracting the configured offset when summer time ends.

Use the following CLI syntax to configure daylight savings time.

config>system>timedst-zone zone-nameend {end-week} {end-day} {end-month} [hours-minutes]offset offsetstart {start-week} {start-day} {start-month} [hours-minutes]

The following example shows the command usage to configure daylight savings time.

Example:
config>system# time
config>system>time# dst-zone pt
	config>system>time>dst-zone# start second sunday april 02:00
	end first sunday october 02:00
	config>system>time>dst-zone# offset 0

If the time zone configured is listed in System-defined time zones , the starting and ending parameters and offset do not need to be configured with this command unless there is a need to override the system defaults. The command will return an error if the start and ending dates and times are not available either in System-defined time zones or entered as optional parameters in this command.

The following is a sample output for the configured parameters.

A:ALA-48>config>system>time>dst-zone# info 
----------------------------------------------
                start second sunday april 02:00
                end first sunday october 02:00
                offset 0
----------------------------------------------
A:ALA-48>config>system>time>dst-zone# offset 0
NTP

Network Time Protocol (NTP) is defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. It enables participating network nodes to keep time more accurately and maintain time in a synchronized manner between all participating network nodes.

NTP time elements include: Authentication-check, Authentication-key, Broadcast, Broadcastclient, NTP-server, Peer, and Server.

Authentication-check

The authentication-check command provides the option to skip the rejection of NTP PDUs that do not match the authentication key or authentication type requirements. The default behavior when authentication is configured is to reject all NTP PDUs that have a mismatch in either the authentication key-id, type, or key.

When authentication-check is configured, NTP PDUs are authenticated on receipt. However, mismatches cause a counter to be incremented, one counter for key-id, one for type, and one for key value mismatches.

Use the following CLI syntax to authenticate NTP PDUs on receipt.

config>system>time>ntp
        authentication-check
Command usage to authenticate NTP PDUs on receipt
 config>system>time>ntp# 
	config>system>time>ntp# authentication-check
	config>system>time>ntp# no shutdown
Authentication-key

This command configures an authentication key ID, key type, and key used to authenticate NTP PDUs sent to and received from other network elements participating in the NTP protocol. For authentication to work, the authentication key ID, authentication type and authentication key value must match.

Use the following CLI syntax to configure an authentication key ID, key type, and key.

config>system>time>ntp
        authentication-key key-id {key key} [hash | hash2] type 
        {des|message-digest}
Command usage

The following example shows the command usage to configure an authentication key ID, key type, and key.

	 config>system>time>ntp# 
	config>system>time>ntp# authentication-key 1 key A type des
	config>system>time>ntp# no shutdown
Configuration output

The following sample configuration shows NTP disabled with the authentication-key parameter enabled.

A:sim1>config>system>time>ntp# info
----------------------------------------------
                shutdown
                authentication-key 1 key "OAwgNUlbzgI" hash2 type des 
----------------------------------------------
A:sim1>config>system>time>ntp# 
Broadcast

The broadcast command is used to transmit broadcast packets on a specific subnet.

Use the following CLI syntax to transmit broadcast packets.

config>system>time>ntp
        broadcast [router router-name]{interface 
            ip-int-name}[key-id key-id] [version version][ttl ttl]
Command usage to transmit broadcast packets
config>system>time>ntp# 
	config>system>time>ntp# broadcast interface int11 version 4 
		ttl 127
	config>system>time>ntp# no shutdown
Configuration output in the system>time context

The following sample configuration of the system>time context shows NTP enabled with the broadcast command configured.

A:sim1>config>system>time# info detail
----------------------------------------------
            ntp
                no shutdown
                authentication-check
                ntp-server
                broadcast interface int11 version 4 ttl 127
            exit
A:sim1>config>system>time#
Configuration output in the config context

The following sample configuration shows NTP enabled in the config context with the broadcast command configured. At this level, the NTP broadcast commands are displayed at the end of the output after the router interfaces are shown.

A:sim1>config info
 
    ....
 
#--------------------------------------------------
echo "System Time NTP Configuration"
#--------------------------------------------------
    system
        time
            ntp
                broadcast interface toboth
            exit
        exit
    exit
A:sim1>config
Broadcastclient

The broadcastclient command enables listening to NTP broadcast messages on the specified interface.

Use the following CLI syntax to enable listening to NTP broadcast messages.

config>system>time>ntp
        broadcastclient[router router-name] {interface ip-int-name} [authenticate]
Command usage to enable listening to NTP broadcast messages
	 config>system>time>ntp# 
	config>system>time>ntp# broadcastclient interface int11
	config>system>time>ntp# no shutdown
Configuration output

The following is a sample configuration of NTP enabled with the broadcastclient parameter enabled.

A:ALA-12>config>system>time# info
----------------------------------------------
            ntp
                broadcastclient interface int11
                no shutdown
            exit
            dst-zone PT
                start second sunday april 02:00
                end first sunday october 02:00
                offset 0
            exit
            zone UTC
----------------------------------------------
A:ALA-12>config>system>time#
NTP-server

This command configures the node to assume the role of an NTP server. Unless the server command is used, this node will function as an NTP client only and will not distribute the time to downstream network elements. If an authentication key-id is specified in this command, the NTP server requires client packets to be authenticated.

Use the following CLI syntax to configure the node to function as an NTP client only.

config>system>time>ntp
        ntp-server [transmit key-id]
Command usage

The following example shows the command usage to configure the node to function as an NTP client only.

 config>system>time>ntp# 
	config>system>time>ntp# ntp-server transmit 1
	config>system>time>ntp# no shutdown
Configuration output

The following is a sample configuration output of NTP enabled with the ntp-server command configured.

A:sim1>config>system>time>ntp# info
----------------------------------------------
        no shutdown
        ntp-server
----------------------------------------------
A:sim1>config>system>time>ntp# 
Peer

Configuration of an NTP peer configures symmetric active mode for the configured peer. Although any system can be configured to peer with any other NTP node, Nokia recommends to configure authentication and to configure known time servers as their peers. Use the no form of the command to remove the configured peer.

Use the following CLI syntax to configure symmetric active mode.

config>system>time>ntp
        peer ip-address [version version][key-id key-id]
        [prefer]
Command usage to configure symmetric active mode
 config>system>time>ntp# 
	config>system>time>ntp# peer 192.168.1.1 key-id 1
	config>system>time>ntp# no shutdown
Configuration output

The following is a sample configuration output of NTP enabled with the peer command configured.

A:sim1>config>system>time>ntp# info
----------------------------------------------
            no shutdown
            peer 192.168.1.1 key-id 1 
----------------------------------------------
A:sim1>config>system>time>ntp# 
Server

The server command is used when the node should operate in client mode with the NTP server specified in the address field. Use the no form of this command to remove the server with the specified address from the configuration. Up to five NTP servers can be configured.

Use the following CLI syntax to configure the node to operate in client mode.

config>system>time>ntp
        server {ip-address |ptp}[key-id key-id] [version version] [prefer]
Command usage

The following example shows the command usage to configure the node to operate in client mode.

 config>system>time>ntp# 
	config>system>time>ntp# server 192.168.1.1 key-id 1
	config>system>time>ntp# no shutdown
Configuration output

The following is a sample configuration of NTP enabled with the server command configured.

A:7210SAS>config>system>time>ntp# info 
----------------------------------------------
                ntp-server
                server ptp prefer
                broadcast interface "a1"
                no shutdown
----------------------------------------------
A:7210SAS>config>system>time>ntp# 
SNTP

SNTP is a compact, client-only version of the NTP. SNTP can only receive the time from SNTP/NTP servers; it cannot be used to provide time services to other systems. SNTP can be configured in either broadcast or unicast client mode.

SNTP time elements include the Broadcast-client and Server-address.

Use the following CLI syntax to configure the SNTP.

config>system
    time
    sntp
        broadcast-client 
        server-address ip-address [version version-number] [normal|preferred] [interval seconds]
        no shutdown
Broadcast-client

The broadcast-client command enables listening at the global device level to SNTP broadcast messages on interfaces with broadcast client enabled.

Use the following CLI syntax to enable listening to SNTP broadcast messages at the global device level.

config>system>time>sntp
        broadcast-client
Command usage

The following example shows the command usage to enable listening to SNTP broadcast messages at the global device level.

 	config>system>time>sntp# 
	config>system>time>sntp# broadcast-client 
	config>system>time>sntp# no shutdown
Configuration output

The following is a sample configuration output of SNTP enabled with the broadcast-client command enabled.

A:ALA-12>config>system>time# info
----------------------------------------------
            sntp
                broadcast-client
                no shutdown
            exit
            dst-zone PT
                start second sunday april 02:00
                end first sunday october 02:00
                offset 0
            exit
            zone GMT
----------------------------------------------
A:ALA-12>config>system>time#
Server-address

The server-address command configures an SNTP server for SNTP unicast client mode.

Use the following CLI syntax to configure an SNTP server for unicast client mode.

config>system>time>sntp#
                    config>system>time>sntp# server-address ip-address version version-number] [normal|preferred] [interval seconds]
Command usage

The following example shows the command usage to configure an SNTP server for unicast client mode.

 	config>system>time>sntp#
	config>system>time# server-address 10.10.0.94 version
		1preferred interval 100
Configuration output

The following is a sample configuration output of SNTP enabled with the server-address command configured.

A:ALA-12>config>system>time# info
----------------------------------------------
            sntp
                server-address 10.10.0.94 version 1 preferred interval 100
                no shutdown
            exit
            dst-zone PT start-date 2006/04/04 12:00 end-date 2006/10/25 12:00
            zone GMT
----------------------------------------------
A:ALA-12>config>system>time#
CRON

The cron command supports the Service Assurance Agent (SAA) functions and the ability to schedule turning on and off policies to meet ‟Time of Day” requirements. CRON functionality includes the ability to specify the commands that need to be run, when they will be scheduled, including one-time only functionality (oneshot), interval and calendar functions, as well as where to store the output of the results. In addition, CRON can specify the relationship between input, output, and schedule. Scheduled reboots, peer turn ups, service assurance agent tests and more can all be scheduled with CRON, as well as OAM events, such as connectivity checks, or troubleshooting runs.

CRON elements include Action, Schedule, Script, Time range, and Time of Day.

Action

Use this command to configure the parameters for a script, including the maximum amount of time to keep the results from a script run, the maximum amount of time a script may run, the maximum number of script runs to store and the location to store the results.

Use the following CLI syntax to configure the parameters for a script.

config>system>cron
    action action-name [owner action-owner]
        expire-time {seconds|forever}
        lifetime {seconds|forever}
        max-completed unsigned
        results file-url
        script script-name [owner script-owner]
        shutdown 
Command usage to configure the parameters for a script
config>system>cron# action test
        config>system>cron>action# results ftp://172.22.184.249/./sim1/test-results
        config>system>cron>action# no shut
Configuration output

The following sample output shows a script named ‟test” receiving an action to store its results in a file called ‟test-results”.

A:sim1>config>system>cron# info
----------------------------------------------
        script "test"
            location "ftp://172.22.184.249/./sim1/test.cfg"
            no shutdown 
        exit
        action "test"
            results "ftp://172.22.184.249/./sim1/test-results"
            no shutdown 
        exit
----------------------------------------------
A:sim1>config>cron# script
Schedule

The schedule function configures the type of schedule to run, including one-time only (oneshot), periodic or calendar-based runs. All runs are determined by month, day of month or weekday, hour, minute and interval (seconds). If end-time and interval are both configured, whichever condition is reached first is applied.

Use the following CLI syntax to configure the type of schedule to run.

config>system>cron
    schedule schedule-name [owner schedule-owner]
        action action-name [owner owner-name] 
        count number
        day-of-month {day-number [..day-number]|all}
        description description-string
        end-time [date | day-name] time
        hour {hour-number [..hour-number] | all}
        interval seconds 
        minute {minute-number [..minute-number]|all} 
        month {month-number [..month-number]|month-name [..month-name]|all} 
        no shutdown 
        type {periodic|calendar|oneshot} 
        weekday {weekday-number [..weekday-number]|day-name [..day-name]|all}
        shutdown
Command usage to configure the type of schedule to run
config>system>cron# schedule test2
    config>system>cron>sched# day-of-month 17 
    config>system>cron>sched# end-time 2007/07/17 12:00
    config>system>cron>sched# minute 0 15 30 45 
    config>system>cron>sched# weekday friday 
    config>system>cron>sched# shut
Configuration output

The following is sample configuration output that schedules a script named ‟test2” to run every 15 minutes on the 17th of each month and every Friday until noon on July 17, 2007.

*A:SR-3>config>system>cron# info 
----------------------------------------------
        schedule "test2"
            shutdown
            day-of-month 17           
            minute 0 15 30 45
            weekday friday 
            end-time 2007/07/17 12:00
        exit
----------------------------------------------
*A:SR-3>config>system>cron# 
Script

The script command opens a new nodal context that contains information about a script.

Use the following CLI syntax to create a nodal context.

config>system>cron
    script script-name [owner script-owner]
        description description-string
        location file-url 
        shutdown 
        
Command usage to create a nodal context called "test"
 config>system>cron# script test
	config>system>cron>script#
Configuration output that names a script "test"
A:sim1>config>system>cron# info
----------------------------------------------
        script "test"
            location "ftp://172.22.184.249/./sim1/test.cfg"
            no shutdown 
        exit
----------------------------------------------
A:sim1>config>system>cron# 
Time range

ACLs and QoS policy configurations may be enhanced to support time-based matching. CRON configuration includes time matching with the schedule subcommand. Schedules are based on events; time-range defines an end-time that is used as a match criteria.

Time range elements include Create, Absolute, Daily, Weekdays, Weekend, and Weekly.

Create

This command can be used to enable the time-range context.

Use the following syntax to create a time-range.

config>system>cron
        time-range name create
Command usage to create a time-range called "test1"
 config>system>cron# time-range test1 create
	config>system>cron>time-range$
Absolute

The absolute command configures a start and end time that will not repeat.

Use the following syntax to configure a non-repetitive time range.

config>system>cron>time-range$
        absolute absolute-time end absolute-time
Command usage to configure a non-repetitive time range
 config>system>cron>time-range$ absolute start 2006/05/05,11:00 end 
	2006/05/06,11:01
	config>system>cron>time-range$

The following is a sample configuration output of an absolute time range beginning on May 5, 2006 at 11:00 and ending May 6, 2006 at 11:01.

A:sim1>config>system>cron>time-range# show cron time-range detail
===============================================================================
Cron time-range details
===============================================================================
Name        : test1
Triggers    : 0
Status      : Inactive
Absolute    : start 2006/05/05,11:00 end 2006/05/06,11:01
===============================================================================
A:sim1>config>system>cron>time-range# 
Daily

The daily command configures the start and end of a periodic schedule for every day of the week (Sunday through Saturday).

Use the following syntax to configure a time range that is repeated daily.

config>system>cron>time-range$
        daily start time-of-day end time-of-day
Command usage to create a time range that is repeated daily
 config>system>cron>time-range$ daily start 11:00 end 12:00
	config>system>cron>time-range$

The following is a sample configuration output of a daily time range beginning at 11:00 and ending at 12:00.

A:sim1>config>system>cron>time-range# show cron time-range detail      
===============================================================================
Cron time-range details
===============================================================================
Name        : 1
Triggers    : 0
Status      : Inactive
Periodic    : daily   Start 11:00 End 12:00
===============================================================================
A:sim1>config>system>cron>time-range# 
Weekdays

The weekdays command configures the start and end of a periodic schedule for weekdays (Monday through Friday).

Use the following syntax to configure a time range that is repeated on weekdays.

config>system>cron>time-range$
        weekdays start time-of-day end time-of-day
Command usage to create a time range that is repeated on weekdays
 config>system>cron>time-range$ weekdays start 11:00 end 12:00
	config>system>cron>time-range$

The following is a sample configuration output of a time range beginning at 11:00 and ending at 12:00. This schedule runs all weekdays during this time period.

A:sim1>config>system>cron>time-range# show cron time-range detail   
===============================================================================
Cron time-range details
===============================================================================
Name        : 1
Triggers    : 0
Status      : Inactive
Periodic    : weekdays Start 11:00 End 12:00
===============================================================================
A:sim1>config>system>cron>time-range# 
Weekend

The weekend command configures the start and end of a periodic schedule for weekends (Saturday and Sunday). The resolution must be at least one minute apart, for example, start at 11:00 and end at 11:01. A start time and end time of 11:00 is invalid.

Use the following syntax to configure a time range that is repeated on weekends.

config>system>cron>time-range$
        weekend start time-of-day end time-of-day
Command usage to create a time range that is repeated on weekends
 	config>system>cron>time-range$ weekend start 11:00 end 12:00
	config>system>cron>time-range$

The following is a sample configuration output of a weekend time range beginning at 11:00am and ending at 12:00pm, both Saturday and Sunday.

To specify 11:00am to 12:00pm on Saturday or Sunday only, use the absolute parameter for one day, or the weekly parameter for every Saturday or Sunday accordingly. In addition, see the schedule parameter to schedule oneshot or periodic events in the config>system>cron context.

A:sim1>config>system>cron>time-range# show cron time-range detail  
===============================================================================
Cron time-range details
===============================================================================
Name        : 1
Triggers    : 0
Status      : Inactive
Periodic    : weekend Start 11:00 End 12:00
Weekly

The weekly command configures the start and end of a periodic schedule for the same day every week, for example, every Friday. The start and end dates must be the same. The resolution must be at least one minute apart, for example, start at 11:00 and end at 11:01. A start time and end time of 11:00 is invalid.

Use the following syntax to configure a time range that is repeated weekly.

config>system>cron>time-range$
        weekly start time-in-week end time-in-week
Command usage to create a time range is repeated weekly
 config>system>cron>time-range$ start fri,01:01 end fri,01:02
	config>system>cron>time-range$
Configuration output

The following is a sample configuration output of a weekly time range beginning on Friday at 1:01am ending Friday at 1:02am.

A:sim1>config>system>cron>time-range$ info
----------------------------------------------
        weekly start fri,01:01 end fri,01:02
----------------------------------------------
A:sim1>config>system>cron>time-range$ 
Time of Day

Time of Day (TOD) suites are useful when configuring many types of time-based policies or when a large number of subscribers or SAPs require the same type of TOD changes. The TOD suite may be configured while using specific ingress or egress ACLs or QoS policies, and is an enhancement of the ingress and egress CLI trees.

Time of day elements include SAPs, Egress, and Ingress.

SAPs
  • If a TOD Suite is assigned to a SAP, statistics collection are not collected for that SAP.

  • When an item is configured both on SAP level and in the TOD suite assigned to the SAP, the TOD-suite defined value takes precedence.

  • A policy or filter assignment configured directly on a SAP has a lower priority than any assignment in a TOD Suite. Therefore, it is possible that a new direct configuration has no immediate effect. If the configuration is made by CLI, a warning is given.

Egress

This command is an enhancement for specific egress policies. Use this command to create time-range based associations of previously created filter lists, QoS and scheduler policies. Multiple policies may be included and each must be assigned a different priority; in case time-ranges overlap, the priority will be used to determine the prevailing policy. Only a single reference to a policy may be included without a time-range.

Filters

In a TOD suite, filters that have entries with time-ranges may not be selected. Similarly, filter entries with a time-range may not be created while a TOD suite refers to that filter. QoS policies and filters referred to by a TOD suite must have scope ‟template” (default).

Use the following syntax to configure TOD-suite egress parameters.

config>system>cron
    tod-suite tod-suite-name create
        egress 
            filter ip ip-filter-id [time-range time-range-name] [priority priority]
            filter ipv6 ipv6-filter-id [time-range time-range-name] [priority priority]
            filter mac mac-filter-id[time-range time-range-name] [priority priority]
Command usage to configure TOD-suite egress parameters
config>system>cron>tod-suite$ egress filter ip 100 
    config>system>cron>tod-suite$
Configuration output

The following is a sample configuration output of an egress IP filter association with filter ID 100.

sim1>config>filter# ip-filter 100 create
A:sim1>config>filter>ip-filter$ entry 10 create
A:sim1>config>filter>ip-filter>entry$ 
A:sim1>config>system>cron>tod-suite# egress filter ip 100
A:sim1>config>system>cron>tod-suite# info detail
----------------------------------------------
            no description
            egress
                filter ip 100 
            exit
----------------------------------------------
A:sim1>config>system>cron>tod-suite# 

Ingress

This command is an enhancement for specific ingress policies including filter lists and QoS policies. Use this command to create time-range based associations of previously created filter lists and QoS policies. Multiple policies may be included and each must be assigned a different priority; in case time-ranges overlap, the priority will be used to determine the prevailing policy. Only a single reference to a policy may be included without a time-range. To configure a daily time-range across midnight, use a combination of two entries. An entry that starts at hour zero will take over from an entry that ends at hour 24.

Use the following syntax to configure time range based associations.

config>system>cron
        tod-suite tod-suite-name create
            ingress
                filter ip ip-filter-id [time-range time-range-name] [priority priority]
                filter ipv6 ipv6-filter-id [time-range time-range-name]
                filter mac mac-filter-id[time-range time-range-name] [priority priority]
                qos policy-id [time-range time-range-name] [priority priority]
Command usage to configure an IP filter association
config>system>cron>tod-suite$ ingress filter ip 100 
    config>system>cron>tod-suite$
Configuration output

The following is a sample configuration output of an ingress IP filter association with filter ID 100.

sim1>config>filter# ip-filter 100 create
A:sim1>config>filter>ip-filter$ entry 10 create
A:sim1>config>filter>ip-filter>entry$ 
...
A:sim1>config>system>cron>tod-suite# ingress filter ip 100
A:sim1>config>system>cron>tod-suite# info detail
----------------------------------------------
            no description
            ingress
                filter ip 100 
            exit
----------------------------------------------
A:sim1>config>system>cron>tod-suite#
Command usage toconfigure an association with a SAP ingress QoS policy
 config>system>cron>tod-suite$ ingress qos 101
	config>system>cron>tod-suite$
Configuration output

The following is a sample configuration output of an association with SAP ingress QoS policy 101.

A:sim1>config>qos# sap-egress 101 create
...
A:sim1>config>system>cron>tod-suite# ingress qos 101 
A:sim1>config>system>cron>tod-suite# info detail
----------------------------------------------
            no description
            ingress
                qos 101 
            exit
----------------------------------------------
A:sim1>config>system>cron>tod-suite#

Configuring backup copies

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

Command usage

The following example shows the command usage to set the maximum number of backup versions of the configuration and index files kept in the primary location to 7.

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

Configuration output for the config-backup command

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#

System administration parameters

This section describes the system administration parameters and the CLI syntax to configure the parameters.

Disconnect

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

Note:

Configuration modifications are saved to the primary image file.

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

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

Command usage to disconnect a user from a session

	admin# disconnect 

Output of the disconnect command

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

C:\>

Set-time

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

Command usage to set the date and time

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

Output of the set-time command

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#

Display-config

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]

Command usage to display the running configuration of the system

admin# display-config detail

Configuration output of the display-config detail command

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

Tech-support

The tech-support command creates a system core dump.

Note:

This command should only be used with explicit authorization and direction from Nokia’s Technical Assistance Center (TAC).

Save

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]

Command usage to save the running configuration

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

Configuration output of the save command

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#

Reboot

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]

Command usage to reboot the router

	admin# reboot now

Output of the reboot command

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

When an admin reboot auto-init command is issued, the system resets the existing BOF and reboots. The system startup process after the admin reboot auto-init command is executed is the same as the first time system boot described in System initialization.

Note:

After the BOF is reset, the system may not boot up with the last saved system configuration unless the new BOF also uses the same configuration file. If you require the system to boot up with the last saved system configuration, Nokia recommends that you should run the admin>save file-url command to save the current system configuration and modify the BOF to use this configuration.

Use the following syntax to reset the BOF and reboot.

admin# reboot auto-init [now]

Output of the admin reboot auto-init command

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.

Post-boot configuration extension files

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          

Command usage

The following example shows the command usage to configure a URL for a CLI script that runs when the boot-up configuration is completed.

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

Command output

*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#

Show command output and console messages

The show>system>information command displays the current value of the bad and good exec URLs and indicates whether a post-boot configuration extension file was executed when the system was booted. If an extension file was executed, the show>system>information command also indicates if it completed successfully.

When executing a post-boot configuration extension file, status messages are output to the CONSOLE screen before the ‟Login” prompt.

The following is a sample output of a failed boot-up configuration that caused a boot-bad-exec file containing another error to be executed.

Attempting to exec configuration file:
’ftp://test:test@192.168.xx.xxx/./12.cfg’ ...
System Configuration
Log Configuration
MAJOR: CLI #1009 An error occurred while processing a CLI command -
File ftp://test:test@192.168.xx.xxx/./12.cfg, Line 195: Command "log" failed.
CRITICAL: CLI #1002 An error occurred while processing the configuration file.
The system configuration is missing or incomplete.
MAJOR: CLI #1008 The SNMP daemon is disabled.
If desired, enable SNMP with the ’config>system>snmp no shutdown’ command.
Attempting to exec configuration failure extension file:
’ftp://test:test@192.168.xx.xxx/./fail.cfg’ ...
Config fail extension
Enabling SNMP daemon
MAJOR: CLI #1009 An error occurred while processing a CLI command -
File ftp://test:test@192.168.xx.xxx/./fail.cfg, Line 5: Command "abc log" failed.
TiMOS-B-x.0.Rx both/hops NOKIA Copyright (c) 2016 Nokia.
All rights reserved. All use subject to applicable license agreements.
Built on Thu Nov 207 19:19:11 PST 2016 by builder in /rel5x.0/b1/Rx/panos/main


Login: 

System timing

When synchronous Ethernet is enabled, the operator can select an Ethernet port as a candidate for timing reference. The timing information recovered from this port is used to time the system.

CLI command syntax for 7210 SAS platforms

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

CLI syntax for 7210 SAS-Mxp

The following is a sample CLI configuration for the 7210 SAS-Mxp.


*A:SAS-M2>config>system>sync-if-timing# info detail
----------------------------------------------
            no ql-selection
            ref-order ref1 ref2 ptp bits1 bits2
            ref1
                source-port 1/1/9
                no shutdown
                no ql-override
            exit
            ref2
                source-port 1/1/19
                no shutdown
                no ql-override
            exit
            bits1
                interface-type e1 pcm31crc
                ssm-bit 8
                no ql-override
                input
                    no shutdown
                exit
                output
                    no shutdown
                exit
            exit
            bits2
                input
                    no shutdown
                exit
                output
                    no shutdown
                exit
            exit
            ptp
                shutdown
                no ql-override
            exit
            no revert
----------------------------------------------
*A:SAS-M2>config>system>sync-if-timing#

CLI syntax for 7210 SAS-R6 and 7210 SAS-R12

The following is a sample CLI configuration for the 7210 SAS-R6 and 7210 SAS-R12.

*A:sasr_dutb>config>system>sync-if-timing# info detail
----------------------------------------------
            no ql-selection
            ref-order bits1 ref1 ref2 ptp
            ref1
                shutdown
                no source-port
                no ql-override
            exit
            ref2
                shutdown
                no source-port
                no ql-override
            exit
            bits1
                interface-type ds1 esf
                no ql-override
                input
                    shutdown
                exit
                output
                    shutdown
                    line-length 110
                exit
            exit
            ptp
                shutdown
                no ql-override
            exit
            no revert
----------------------------------------------
*A:sasr_dutb>config>system>sync-if-timing#

CLI syntax for 7210 SAS-Sx/S 1/10GE

The following is a sample CLI configuration for the 7210 SAS-Sx/S 1/10GE.

*7210SAS>config>system>sync-if-timing# info detail
----------------------------------------------
            no ql-selection
            ref-order ref1 ref2
            ref1
                shutdown
                no source-port
                no ql-override
            exit
            ref2
                shutdown
                no source-port
                no ql-override
            exit
            no revert
----------------------------------------------
*7210SAS>config>system>sync-if-timing#

CLI syntax for 7210 SAS-T

The following is a sample CLI configuration for the 7210 SAS-T.

*A:SAS>config>system>sync-if-timing# info detail
----------------------------------------------
            no ql-selection
            ref-order ref1 ref2 ptp bits1 bits2
            ref1
                shutdown
                no source-port
                no ql-override
            exit
            ref2
                shutdown
                no source-port
                no ql-override
            exit
            bits1
                interface-type ds1 esf
                no ql-override
                input
                    shutdown
                exit
                output
                    shutdown
                    line-length 110
                exit
            exit
            bits2
                input
                    shutdown
                exit
                output
                    shutdown
                exit
            exit
            ptp
                shutdown
                no ql-override
            exit
            no revert
----------------------------------------------
*A:SAS>config>system>sync-if-timing#

Entering edit mode

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

The following is a sample error message that is displayed if you try to modify sync-if-timing parameters without entering the begin keyword.

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#
Note:

Use commit to save or abort to discard the changes made in a session.

Configuring timing references

Configuration of timing reference parameters

config>system# sync-if-timing
config>system>sync-if-timing# begin
config>system>sync-if-timing# ref1
config>system>sync-if-timing>ref1# source-port 1/1/1
config>system>sync-if-timing>ref1# no shutdown
config>system>sync-if-timing>ref1# exit
config>system>sync-if-timing# ref2
config>system>sync-if-timing>ref2# source-port 1/1/2
config>system>sync-if-timing>ref2# no shutdown
config>system>sync-if-timing>ref2# exit
config>system>sync-if-timing>commit

Configuration output of the timing reference parameters

*7210-SAS>config>system>sync-if-timing#info detail
 
----------------------------------------------
ref-order ref1 ref2
ref1
source-port 1/1/1
no shutdown
exit
ref2
source-port 1/1/2
no shutdown
exit
no revert
----------------------------------------------

Using the revert command

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

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

Forcing a specific reference

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

Note:

The debug sync-if-timing force-reference command should only be used to test and debug problems. After the system timing reference input has been forced, it will not revert to another reference unless explicitly reconfigured, or if the forced reference fails, or if the received QL code is QL-DNU/DUS and QL selection is enabled.

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}

The following example shows the command usage to reference the current system synchronous timing output from the specifies reference input.

debug>sync-if-timing# force-reference

Configuring system monitoring thresholds

This section describes how to configure system monitoring thresholds.

Creating events

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.

To create events, use the following sample CLI configuration.

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"

Command output

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#

System alarm contact inputs

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

Configuring 1830 VWM

Configuraiton output for the creation of a vwm-shelf

Note:

Card 1 corresponds to slot #1 and card 2 corresponds to slot #2 on the 1830 CWDM device. The optical modules or line cards are inserted into these slots.

*A:NS1333C2676# configure system vwm-shelf 3 vwm-type ec-cw create 
*A:NS1333C2676>configure>system>vwm-shelf$ info 
----------------------------------------------
            no shutdown
----------------------------------------------
*A:NS1333C2676>configure>system>vwm-shelf$ info detail 
----------------------------------------------
            card 1
                shutdown
                no card-type
            exit
            card 2
                shutdown
                no card-type
            exit
            no shutdown
*A:NS1333C2676>configure>system>vwm-shelf$

*A:7210 SAS>show system vwm-shelf 7 

===========================================================================
Shelf Summary
===========================================================================
Shelf-ID   USB/     Shelf           Admin       Oper        Number of
           OMC      Type            State       State       Equipped slots
---------------------------------------------------------------------------
7          OMC      CWDM            UP          UP          2

===========================================================================
Slot Summary
===========================================================================
Slot-ID    Provisioned        Equipped       Admin          Oper
           Type               Type           State          State
---------------------------------------------------------------------------
1          Not Provisioned    SFC1D          DOWN           DOWN
2          Not Provisioned    SFC2A&B        DOWN           DOWN
A          CWDM               CWDM           UP             UP
===========================================================================
*A:7210SAS#


*A:7210SAS# show system vwm-shelf 7 detail 

===========================================================================
Shelf Summary
===========================================================================
Shelf-ID   USB/     Shelf           Admin       Oper        Number of
           OMC      Type            State       State       Equipped slots
---------------------------------------------------------------------------
7          OMC      CWDM            UP          UP          2

===========================================================================
Slot Summary
===========================================================================
Slot-ID    Provisioned        Equipped       Admin          Oper
           Type               Type           State          State
---------------------------------------------------------------------------
1          SFC1D              SFC1D          UP             UP
2          SFC2A&B            SFC2A&B        UP             UP
A          CWDM               CWDM           UP             UP

===========================================================================
1830 VWM Shelf Controller-A Hardware Data
===========================================================================
No of Slots             : 2           
Part Number             : 3KC19297AAAB01
CLEI code               : WOCUAZNUTA  
Unit Mnemonic           : EC-CW       
Serial Number           : EZ444555666     
Manufacturing Date      : 12112000    
Administrative state    : UP          
Operational state       : UP          
Firmware version        : --------------
Current Alarm state     : Cleared     
                                      
===========================================================================
1830 VWM Slot/Module Hardware Data    
===========================================================================
Slot Number             : 1           
Provisioned type        : SFC1D       
Equipped type           : Equipped (SFC1D)
Part Number             : 3KC19289AEAA01
CLEI code               : ----------  
Unit Mnemonic           : SFC1D       
Serial Number           : EZ121130171     
Manufacturing Date      : 03192012    
Operational state       : UP          
Firmware version        : --------------
Current Alarm state     : Cleared     
                                      
===========================================================================
1830 VWM Slot/Module Hardware Data    
===========================================================================
Slot Number             : 2           
Provisioned type        : SFC2A&B     
Equipped type           : Equipped (SFC2A&B)
Part Number             : 3KC19289AKAA  
CLEI code               : WOCUAZNUTA  
Unit Mnemonic           : SFC2A&B     
Serial Number           : EZ120630634     
Manufacturing Date      : 12122000    
Operational state       : UP          
Firmware version        : --------------
Current Alarm state     : Cleared     
===========================================================================
                                      
*7210SAS# 

Configuration output for the deletion of a vwm-shelf

*7210SAS>configure>system>vwm-shelf$ info 
----------------------------------------------
            card 2
                card-type SF
----------------------------------------------
7210SAS>configure>system>vwm-shelf$ 

*7210SAS>configure>system>vwm-shelf$ info 
----------------------------------------------
            card 2
                card-type SFC1D
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A AS-M>configure>system>vwm-shelf$ card 2 no card-type 
*A AS-M>configure>system>vwm-shelf$ info 
----------------------------------------------
            no shutdown
----------------------------------------------

Configuring LLDP

Use the following syntax to configure LLDP.

config>system>lldp
        tx-interval <interval>
        tx-hold-multiplier <multiplier>
        reinit-delay <time>
        notification-interval <time>
        tx-credit-max <count>
        message-fast-tx <time>
        message-fast-init <count>
        shutdown

LLDP port configuration

*A:7210-SAS>config>port>ethernet>lldp# info
----------------------------------------------
       dest-mac nearest-bridge
              admin-status tx-rx
              tx-tlvs port-desc sys-cap
              tx-mgmt-address system
       exit
----------------------------------------------
*A:7210-SAS>config>port>ethernet>lldp#

Global system LLDP configuration


A:7210-SAS>config>system>lldp# info
----------------------------------------------
        tx-interval 10
        tx-hold-multiplier 2
        reinit-delay 5
        notification-interval 10
----------------------------------------------
A:7210-SAS>config>system>lldp#

System command reference

Command hierarchies

Configuration commands

System information commands
config
    - system 
        - boot-bad-exec file-url
        - no boot-bad-exec 
        - boot-good-exec file-url
        - no boot-good-exec
        - chassis
            - allow-imm-family imm-family
            - no allow-imm-family
        - clli-code clli-code
        - no clli-code
        - config-backup count
        - no config-backup
        - contact contact-name
        - no contact
        - coordinates coordinates
        - no coordinates
        - dhcp6
            - [no] snooping-enable
        - ip 
            - [no] allow-cpu-fragmentation
        - lacp-system-priority lacp-system-priority
        - no lacp-system-priority
        - lldp
        - location location
        - no location
        - login-control
        - name system-name
        - no name
        - oper-group name [create]
        - no oper-group name
            - hold-time
                - group-down time in seconds
                - no group-down
                - group-up time in seconds
                - no group-up

VWM shelf management commands for 7210 SAS-R6 and 7210 SAS-R12

config
    - system 
        - [no] vwm-shelf vwm-shelf-id [create] 
            - card card-id
                - [no] card-type card-type
                - [no] shutdown
            - [no] shutdown

VWM shelf management commands for 7210 SAS-Mxp and 7210 SAS-T

config
    - system 
        - [no] vwm-shelf vwm-shelf-id [vwm-type vwm-type] [create]
            - card card-id
                - [no] card-type card-type
                - [no] shutdown
            - [no] shutdown

System alarm commands

config
    - system
        - thresholds
            - cflash-cap-alarm cflash-id rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no cflash-cap-alarm cflash-id
            - cflash-cap-warn cflash-id rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no cflash-cap-warn cflash-id 
            - kb-memory-use-alarm rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no kb-memory-use-alarm
            - kb-memory-use-warn rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no kb-memory-use-warn
            - memory-use-alarm rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no memory-use-alarm
            - memory-use-warn rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]
            - no memory-use-warn
            - [no] rmon
                - alarm rmon-alarm-id variable-oid oid-string interval seconds [sample-type] [startup-alarm alarm-type] [rising-event rmon-event-id rising-threshold threshold] [falling event rmon-event-id falling-threshold threshold] [owner owner-string]
                - no alarm rmon-alarm-id
                - event rmon-event-id [event-type] [description description-string] [owner owner-string]
                - no event rmon-event-id 

PTP commands

config
    - system 
        - ptp
            - anno-rx-timeout count
            - no anno-rx-timeout 
            - clock
                - freq-source freq-source
                - no freq-source
            - clock-type boundary
            - clock-type ordinary {slave}
            - domain domain-value
            - no domain 
            - local-priority priority
            - log-anno-interval log-interval
            - no log-anno-interval 
            - log-sync-interval values
            - no log-sync-interval 
            - network-type {sdh | sonet}
            - peer ip-address [create]
            - no peer ip-address
                - local-priority priority
                - [no] shutdown
            - port port-id [create]
            - no port port-id
                - address {01:1b:19:00:00:00 | 01:80:c2:00:00:0e}
                - local-priority priority
                - master-only {true | false}
                - [no] shutdown
            - priority1 priority-value
            - no priority1
            - priority2 priority-value
            - no priority2
            - profile {g8265dot1-2010 | ieee1588-2008 | g8275dot1-2014}
            - [no] shutdown

System time commands

root
    - admin
        - set-time [date] [time] 
config
    - system 
        - time
            - [no] ntp
                - [no] authentication-check
                - authentication-key key-id key key [hash | hash2] type {des | message-digest}
                - no authentication-keykey-id
                - [no] broadcast [router router-name] {interface ip-int-name} [key-id key-id]  [version version] [ttl ttl]
                - [no] broadcast [router router-name] {interface ip-int-name}
                - broadcastclient [router router-name] {interface ip-int-name} [authenticate]
                - [no] broadcastclient [router router-name] {interface ip-int-name}
                - [no] ntp-server [authenticate]
                - [no] peer ip-address [version version] [key-id key-id] [prefer]
                - [no] server {ip-address | ptp} [version version] [key-id key-id] [prefer]
                - [no] shutdown
            - [no] sntp
                - [no] broadcast-client 
                - server-address ip-address [version version-number] [normal | preferred] [interval seconds]
                - no server-address ip-address
                - [no] shutdown
            - [no] dst-zone [std-zone-name | non-std-zone-name]
                - end {end-week} {end-day} {end-month} [hours-minutes]
                - offset offset
                - start {start-week} {start-day} {start-month} [hours-minutes]
            - zone std-zone-name | non-std-zone-name [hh [:mm]] 
            - no zone

CRON commands

config
    - system
        - cron
            - schedule schedule-name [owner schedule-owner]
            - no schedule
                - count number
                - no count
                - day-of-month {day-number [..day-number] | all}
                - no day-of-month 
                - description description-string 
                -  no description 
                - end-time [date | day-name] time
                - no end-time 
                - hour {..hour-number [..hour-number]|all} 
                - no hour
                - interval seconds 
                - no interval
                - minute {minute-number [..minute-number]|all} 
                - no minute 
                - month {month-number [..month-number]|month-name [..month-name]|all}
                - no month 
                - script-policy script-policy-name [owner script-policy-owner]
                - no script-policy
                - shutdown
                - no shutdown
                - type schedule-type 
                - weekday {weekday-number [..weekday-number]|day-name [..day-name]|all}
                - noweekday 
            - time-range name [create]
            - no time-range 
                - absolute start start-absolute-time end end-absolute-time
                - no absolute start start-absolute-time
                - daily start start-time-of-day end end-time-of-day
                -  no daily start start-time-of-day
                - description description-string 
                - nodescription 
                - weekdays start start-time-of-day end end-time-of-day
                - no weekdays start start-time-of-day
                - weekend start start-time-of-day end end-time-of-day
                - no weekend start start-time-of-day
                - weekly start start-time-in-week end end-time-in-week
                - no weekly start start-time-in-week
            - [no] tod-suite tod-suite-name [create] 
                - [no] description description-string 
                - egress 
                    - filter ip ip-filter-id [time-range time-range-name] [priority priority] 
                    - filter ipv6 ipv6-filter-id [time-range time-range-name] [priority priority] 
                    - filter mac mac-filter-id [time-range time-range-name] [priority priority]
                    - no filter ip ip-filter-id [time-range time-range-name] 
                    - no filter ipv6 ipv6-filter-id [time-range time-range-name] 
                    - no filter mac mac-filter-id [time-range time-range-name]
                - ingress
                    - filter ip ip-filter-id [time-range time-range-name] [priority priority] 
                    - filter ipv6 ipv6-filter-id [time-range time-range-name] [priority priority]
                    - filter mac mac-filter-id [time-range time-range-name] [priority priority] 
                    - no filter ip ip-filter-id [time-range time-range-name] 
                    - no filter ipv6 ipv6-filter-id [time-range time-range-name]
                    - no filter mac mac-filter-id [time-range time-range-name]
                    - qos policy-id [time-range time-range-name] [priority priority] 
                    - no qos policy-id [time-range time-range-name]

System administration (admin) commands

root
    - admin
        - auto-init stop
        - debug-save file-url
        - disconnect {address ip-address | username user-name | console | telnet | ftp | ssh | netconf}
        - display-config [detail | index]
        - [no] enable-tech
        - radius-discovery
        - reboot [upgrade] [auto-init] [now]
        - reboot [active | standby | upgrade] [auto-init {chassis-role factory-default | satellite | standalone}] [now]
        - reboot [file-url] [detail] [index]
        - set-time date / time
        - tech-support [file-url]
        - virtual-chassis {slotid | slotid-range} image-sync

Configuration rollback commands for the 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-Mxp

root
    - admin
        - rollback
            - compare [to checkpoint2]
            - compare checkpoint1 to checkpoint2
            - delete checkpoint | rescue
            - revert checkpoint | rescue [now]
            - save [comment comment] [rescue]
            - view [checkpoint | rescue]
config
    - system 
        - rollback
            - local-max-checkpoints [1..50]
            - no local-max-checkpoints
            - remote-max-checkpoints [1..200]
            - no remote-max-checkpoints
            - rescue-location file-url
            - rollback-location file-url/rollback filename
        - switchover-exec file-url
        - no switchover-exec
        - rollback-sync
        - no rollback-sync
    - redundancy
        - synchronize {boot-env | config}
        - no synchronize

Multi-chassis LAG commands

config
    - redundancy
        - multi-chassis
            -  peer ip-address [create]
            - no peer ip-address
                - authentication-key authentication-key | hash-key [hash | hash2]
                - no authentication-key
                - description description-string
                - no description
                - [no] mc-lag
                    - hold-on-neighbor-failure multiplier
                    - no hold-on-neighbor-failure
                    - keep-alive-interval interval
                    - no keep-alive-interval
                    - lag lag-id lacp-key admin-key system-id system-id [remote-lag remote-lag-id] system-priority system-priority
                    - lag lag-id [remote-lag remote-lag-id]
                    -  no lag lag-id
                    - [no] shutdown
                - peer-name name
                - no peer-name
                - [no] shutdown
                - source-address ip-address
                - no source-address
                - [no] sync
                    - [no] igmp
                    - [no] igmp-snooping
                    - port port-id [sync-tag sync-tag] [create]
                    - no port port-id
                        - range encap-range sync-tag sync-tag
                        - no range encap-range
                    - [no] shutdown

System port LAG MAC assignment commands for 7210 SAS-Mxp standalone, 7210 SAS-T, 7210 SAS-Sx 10/100GE standalone, and 7210 SAS-Sx 1/10GE: standalone and standalone-VC

config
    - system
        - port-lag-mac-assignment [v1-enable]
        - no port-lag-mac-assignment 

System synchronization commands for 7210 SAS-T

config
    - system 
        - sync-if-timing
            - abort
            - begin
            - bits1
                - input
                    - no shutdown
                    - shutdown
                - interface-type {ds1 [{esf|sf}] | e1 [{pcm30crc|pcm31crc}]}
                - no interface-type
                - output
                    - line-length {110|220|330|440|550|660}
                    - no shutdown
                    - shutdown
                - no ql-override
                - ql-override {prs|stu|st2|tnc|st3e|st3|prc|ssua|ssub|sec}
                - ssm-bit sa-bit
            - bits2
                - input
                    - no shutdown
                    - shutdown
                - output
                    - no shutdown
                    - shutdown
            - commit
            - ref-order first second [third] [fourth] [fifth]
            - no ref-order
            - ptp
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec}
                - no ql-override
                - [no] shutdown
            - ref1
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - ref2
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - [no] ql-selection
            - [no] revert

System synchronization commands for 7210 SAS-Mxp

config
    - system 
        - sync-if-timing
            - abort
            - begin
            - bits1
                - input
                    - no shutdown
                    - shutdown
                - interface-type {ds1 [{esf | sf}] | e1 [{pcm30crc | pcm31crc}]}
                - no interface-type
                - output
                    - line-length {110 | 220 | 330 | 440 | 550 | 660}
                    - no shutdown
                    - shutdown
                - no ql-override
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec}
                - ssm-bit sa-bit
            - bits2
                - input
                    - no shutdown
                    - shutdown
                - output
                    - no shutdown
                    - shutdown
            - commit
            - ref-order first second [third] [fourth] [fifth]
            - no ref-order
            - ref1
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - ref2
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - [no] ql-selection
            - [no] revert

System synchronization commands for 7210 SAS-R6 and 7210 SAS-R12

config
    - system 
        - sync-if-timing
            - abort
            - begin
            - bits1
                - input
                    - no shutdown
                    - shutdown
                - interface-type {ds1 [{esf | sf}] | e1 [{pcm30crc | pcm31crc}]}
                - no interface-type
                - output
                    - line-length {110 | 220 | 330 | 440 | 550 | 660}
                    - no shutdown
                    - shutdown
                - no ql-override
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec}
                - ssm-bit sa-bit
            - commit
            - ref-order first second [third] [fourth]
            - no ref-order
            - ptp
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec}
                - no ql-override
                - [no] shutdown
            - ref1
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - ref2
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - [no] ql-selection
            - [no] revert

System synchronization commands for 7210 SAS-Sx 1/10GE, 7210 SAS-S 1/10GE, and 7210 SAS-Sx 10/100GE

config
    - system 
        - sync-if-timing
            - abort
            - begin
            - commit
            - ref-order first second third
            - no ref-order
            - ref1
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - ref2
                - ql-override {prs | stu | st2 | tnc | st3e | st3 | prc | ssua | ssub | sec | eec1 | eec2}
                - no ql-override
                - [no] shutdown
                - source-port port-id
                - no source-port
            - [no] ql-selection
            - [no] revert

LLDP system commands

configure
    - system
        - lldp 
            - lldp-med 
                - network-policy network-policy-id [create] 
                - no network-policy network-policy-id 
                - application-type {voice | voice-signaling | guest-voice | guest-voice-signaling | soft-phone-voice | video-conferencing | streaming-video | video-signaling} 
                - no application-type 
                - dot1p dot1p-value
                - no dot1p 
                - ip-dscp ip-dscp
                - no ip-dscp 
                - vlan-id 0..4094
                - no vlan-id 
                - [no] vlan-tag-present 
            - message-fast-tx time
            - no message-fast-tx
            - message-fast-tx-init count
            - no message-fast-tx-init
            - notification-interval time
            - no notification-interval
            - reinit-delay time
            - no reinit-delay
            - [no] shutdown
            - tx-credit-max count
            - no tx-credit-max
            - tx-hold-multiplier multiplier
            - no tx-hold-multiplier
            - tx-interval interval
            - no tx-interval

System resource-profile commands for 7210 SAS-T

System resource-profile commands for 7210 SAS-Mxp

configure
    - system
        - resource-profile
        - no resource-profile
            - egress-internal-tcam
                - acl-sap-egress [num-resources]
                - no acl-sap-egress
                    - ipv4-ipv6-128-match-enable num-resources
                    - no ipv4-ipv6-128-match-enable
                    - mac-ipv4-match-enable num-resources
                    - no mac-ipv4-match-enable
                    - mac-ipv6-64bit-match-enable num-resources
                    - no mac-ipv6-64bit-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
            - ingress-internal-tcam
                - acl-sap-ingress [num-resources]
                - no acl-sap-ingress
                    - ipv4-ipv6-128-match-enable num-resources
                    - no ipv4-ipv6-128-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-64-only-match-enable num-resources
                    - no ipv6-64-only-match-enable
                    - mac-match-enable num-resources 
                    - no mac-match-enable
                -  dhcp-snooping-sdp-resource [num-resources] 
                -  no dhcp-snooping-sdp-resource 
                - eth-cfm [num-resources] 
                - no eth-cfm
                    - down-mep num-resources
                    - no down-mep 
                    - up-mep num-resources 
                    - no up-mep 
                - ip-mpls-protocols num-resources
                - no ip-mpls-protocols
                - qos-access-port-ingress-resource num-resources
                - no qos-access-port-ingress-resource
                - qos-sap-egress-resource num-resources 
                - no qos-sap-egress-resource
                - qos-sap-ingress-resource num-resources
                - no qos-sap-ingress-resource 
                    - ip-dscp-port-if-match-enable num-resources 
                    - no ip-dscp-port-if-match-enable 
                    - ipv4-mac-match-enable num-resources
                    - no ipv4-mac-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-ipv4-match-enable num-resources
                    - no ipv6-ipv4-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
                - no sap-aggregate-meter
                - sap-aggregate-meter num-resources
            - qos 
                - no port-scheduler-mode 
                - port-scheduler-mode
            - sap-scale-mode mode
            - no sap-scale-mode

System resource-profile commands for 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE

configure
    - system
        - resource-profile 
        - no resource-profile 
            - egress-internal-tcam
                - acl-sap-egress [num-resources]
                - no acl-sap-egress
                    - [no] ipv6-128bit-match-enable num-resources
                    - mac-ipv4-match-enable num-resources
                    - no mac-ipv4-match-enable
                    - mac-ipv6-64bit-match-enable num-resources
                    - no mac-ipv6-64bit-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
                - egress-sap-aggregate-meter num-resources
                - no egress-sap-aggregate-meter num-resources
            - ingress-internal-tcam
                - acl-sap-ingress [num-resources]
                - no acl-sap-ingress
                    - ipv4-ipv6-128-match-enable num-resources
                    - no ipv4-ipv6-128-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-64-only-match-enable num-resources
                    - no ipv6-64-only-match-enable
                    - mac-match-enable num-resources 
                    - no mac-match-enable
                -  dhcp-snooping-sdp-resource [num-resources] 
                -  no dhcp-snooping-sdp-resource 
                - eth-cfm [num-resources] 
                - no eth-cfm
                    - up-mep num-resources 
                    - no up-mep 
                    - down-mep num-resources 
                    - no down-mep
                - qos-access-port-ingress-resource num-resources 
                - no qos-access-port-ingress-resource 
                - qos-sap-ingress-resource [num-resources]
                - no qos-sap-ingress-resource
                    - ipv4-mac-match-enable num-resources
                    - no ipv4-mac-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-ipv4-match-enable num-resources
                    - no ipv6-ipv4-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
                - no sap-aggregate-meter
                - sap-aggregate-meter num-resources
            - sap-scale-mode mode 
            - no sap-scale-mode 

System resource-profile commands for a Virtual Chassis

System resource-profile commands for 7210 SAS-R6 and 7210 SAS-R12

configure
    - system
        - resource-profile policy-id [create]
        - no resource-profile policy-id 
            - description description-string
            - no description
            - egress-internal-tcam
                - acl-sap-egress [num-resources]
                - no acl-sap-egress
                    - [no] ipv6-128bit-match-enable num-resources
                    - mac-ipv4-match-enable num-resources
                    - no mac-ipv4-match-enable
                    - mac-ipv6-64bit-match-enable num-resources
                    - no mac-ipv6-64bit-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
                - egress-sap-aggregate-meter num-resources
                - no egress-sap-aggregate-meter num-resources
                - eth-cfm [num-resources]
                - no eth-cfm
                    - bidir-mip-egress [num-resources]
                    - no bidir-mip-egress
            - g8032-control-sap-tags vlan-range
            - no g8032-control-sap-tags
            - ingress-internal-tcam
                - acl-sap-ingress [num-resources]
                - no acl-sap-ingress
                    - ipv4-ipv6-128-match-enable num-resources
                    - no ipv4-ipv6-128-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-64-only-match-enable num-resources
                    - no ipv6-64-only-match-enable
                    - mac-match-enable num-resources 
                    - no mac-match-enable
                - cpu-protection [num-resources] 
                - no cpu-protection] 
                - eth-cfm [num-resources] 
                - no eth-cfm
                    - up-mep num-resources 
                    - no up-mep 
                    - down-mep num-resources 
                    - no down-mep
                - qos-access-port-ingress-resource num-resources
                - no qos-access-port-ingress-resource
                - qos-network-ingress-resource [num-resources]
                - no qos-network-ingress-resource
                - qos-sap-egress-resource num-resources
                - no qos-sap-egress-resource
                - qos-sap-ingress-resource [num-resources]
                - no qos-sap-ingress-resource
                    - ip-dscp-port-if-match-enable num-resources 
                    - no ip-dscp-port-if-match-enable 
                    - ipv4-mac-match-enable num-resources
                    - no ipv4-mac-match-enable
                    - ipv4-match-enable num-resources
                    - no ipv4-match-enable
                    - ipv6-ipv4-match-enable num-resources
                    - no ipv6-ipv4-match-enable
                    - mac-match-enable num-resources
                    - no mac-match-enable
                - no sap-aggregate-meter
                - sap-aggregate-meter num-resources

Global system resource profile commands for 7210 SAS-R6 and 7210 SAS-R12

Show commands

show
    - alarm-contact-input alarm-contact-input-id [detail]
    - alarm-contact-input all 
    - chassis [environment] [power-supply]
    - system
        - chassis [imm-family]
        - chassis {active | configured}
        - connection [address ip-address [interface interface-name]] [port port-number] [detail]
        - cpu [sample-period seconds] 
        - cron
            - schedule action-name [owner owner-name]
            - tod-suite tod-suite-name [detail] associations failed-associations
            - time-range name associations [detail]
        - global-res-profile [detail] 
        - global-res-profile {active | configured}
        - information
        - lldp
        - memory-pools
        - ntp [{peers | peer peer-address} | {servers | server server-address} | [all]] [detail]
        - rollback [rescue]
        - resource-profile [active|configured] policy-id [detail]
        - ptp
            - peer ip-address [router router-instance | service-name service-name] [detail]
            - peers [router router-instance | service-name service-name] [detail]
            - port port-id [detail]
            - statistics
            - unicast [router router-instance | service-name service-name]
        - sntp
        - sync-if-timing
        - script-control
            - script [script-name] [owner script-owner]
            - script-policy script-policy-name [owner owner-name]
            - script-policy run-history [run-state]
        - thresholds
        - time
        - vwm-shelf vwm-shelf-id [detail] 
        - time
    - redundancy
        - multi-chassis
            - all [detail]
            - mc-lag peer [ip-address] [lag lag-id]
            - mc-lag [peer ip-address [lag lag-id]] statistics
            - sync [peer ip-address]
            - sync peer ip-address detail
        - synchronization
    - pools
    - force-reference
    - oper-group [group-name]
    - oper-group group-name [detail]
    - oper-group group-name [monitoring]
    - uptime

Command descriptions

Configuration commands

Generic commands
shutdown
Syntax

[no] shutdown

Context

config>system>ptp

config>system>time>ntp

config>system>time>sntp

config>system>cron>sched

config>system>script-control>script-policy

config>system>script-control>script

config>system>sync-if-timing>ref1

config>system>sync-if-timing>ref2

config>redundancy>multi-chassis>peer

config>redundancy>multi-chassis>peer>mc-lag

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description
Note:

The config>redundancy>multi-chassis>peer and config>redundancy>multi-chassis>peer>mc-lag contexts are not supported on 7210 SAS platforms configured in the access-uplink operating mode

This command administratively disables the entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

The no form of this command places the entity into an administratively enabled state.

Default

no shutdown

Special Cases
PTP Protocol Handling

Applies only to 7210 SAS-Mxp. When the no shutdown command is issued in the configure>system>ptp context, resources are allocated to enable processing of the protocol by the node. When the shutdown command is issued in the configure>system>ptp context, the resources are deallocated.

Note:

Resources for PTP are allocated when the protocol is enabled in the base routing instance. Resources are deallocated when the configuration of the last PTP context under the base routing instance is shutdown

description
Syntax

description description-string

no description

Context

config>system>cron>sched

config>system>cron>time-range

config>system>cron>tod-suite

config>system>script-control>script

config>redundancy>multi-chassis>peer

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description
Note:

The config>redundancy>multi-chassis>peer context is not supported on 7210 SAS platforms configured in the access-uplink operating mode

This command creates a text description stored in the configuration file for a configuration context.

The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

Parameters
string

Specifies the description character string. Allowed values are any string up to 80 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

System information commands
boot-bad-exec
Syntax

boot-bad-exec file-url

no boot-bad-exec

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures a URL for a CLI script to exec following a failure of a boot-up configuration. The command specifies a URL for the CLI scripts to be 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).

See the exec command for related commands. This command executes the contents of a text file as if they were commands entered at the console.

Default

no boot-bad-exec

Parameters
file-url

Specifies the location and name of the CLI script file executed following failure of the boot-up configuration file execution. When this parameter is not specified, no CLI script file is executed.

Values

file url local-url | remote-url: 255 chars max

local-url — [cflash-id/ | usb-flash-id][file-path]

remote-url — [{ftp://} login:pswd@remote-locn/][file-path]

remote-locn — [hostname | ipv4-address]

  • ipv4-address— a.b.c.d

usb-flash-id

uf1: (7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE: standalone and standalone-VC, and 7210 SAS-Sx 10/100GE)

uf1:, uf1-A:, uf1-B: (7210 SAS-R6 and 7210 SAS-R12)

cflash-id

cf1:, cf2: (7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 10/100GE, and 7210 SAS-Sx 1/10GE: standalone and standalone-VC)

cf2:, cf2-A:, cf2-B: (7210 SAS-R6 and 7210 SAS-R12)

boot-good-exec
Syntax

boot-good-exec file-url

no boot-good-exec

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

Use this command to configure a URL for a CLI script to exec following the success of a boot-up configuration.

See the exec command for related commands. This command executes the contents of a text file as if they were commands entered at the console.

Default

no boot-good-exec

Parameters
file-url

Specifies the location and name of the CLI script file executed following failure of the boot-up configuration file execution. When this parameter is not specified, no CLI script file is executed.

Values

file url local-url | remote-url: 255 chars max

local-url — [cflash-id/ | usb-flash-id][file-path]

remote-url — [{ftp://} login:pswd@remote-locn/][file-path]

remote-locn — [hostname | ipv4-address]

  • ipv4-address — a.b.c.d

usb-flash-id

uf1: (7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE: standalone and standalone-VC, and 7210 SAS-Sx 10/100GE)

uf1:, uf1-A:, uf1-B: (7210 SAS-R6 and 7210 SAS-R12)

cflash-id

cf1:, cf2: (7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 10/100GE, and 7210 SAS-Sx 1/10GE: standalone and standalone-VC)

cf2:, cf2-A:, cf2-B: (7210 SAS-R6 and 7210 SAS-R12)

allow-imm-family
Syntax

allow-imm-family imm-family

no allow-imm-family

Context

config>system>chassis

Platforms

7210 SAS-R6 and 7210 SAS-R12

Description

This command allows the users to configure the type of IMM they plan to use with the chassis. The type of IMM planned to be used in a chassis needs to be configured up-front, so that on system boot, the software can allocate appropriate resources based on the IMM type.

The software checks that the IMMs provisioned (and equipped) in the chassis is a member of the IMM family type currently configured (active value) by the user. If the user provisioned IMM does not match the IMM types allowed, the software detects a errors in provisioning mismatch and marks the operational state of the IMM to be down.

Note:

  • The user can add in support for any IMM family type by repeated execution of this command. IMM family type will be added, only if the current supported family types are compatible with each other, else an error is returned.

  • A change in the current value of IMM family requires a reboot of the node to take effect. therefore, the user configured value for IMM family type takes effect only after the next reboot.

Default

no allow-imm-family

Parameters
imm-family

Specifies the type of IMM family type to be used in a chassis.

Values

imm-sas-r-b, imm-sas-r-c

Default

imm-sas-r-b

clli-code
Syntax

clli-code clli-code

no clli-code

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command creates a Common Language Location Identifier (CLLI) code string for the router. A CLLI code is an 11-character standardized geographic identifier that uniquely identifies geographic locations and certain functional categories of equipment unique to the telecommunications industry.

No CLLI validity checks other than truncating or padding the string to eleven characters are performed.

Only one CLLI code can be configured, if multiple CLLI codes are configured the last one entered overwrites the previous entry.

The no form of this command removes the CLLI code.

Parameters
clli-code

Specifies the 11 character string CLLI code. Any printable, seven bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. If more than 11 characters are entered, the string is truncated. If less than 11 characters are entered the string is padded with spaces.

config-backup
Syntax

config-backup count

no config-backup

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures the maximum number of backup versions maintained for configuration files and BOF.

For example, assume count is set to 5, and the configuration file is called xyz.cfg. When a save command is executed, the file xyz.cfg is saved with a .1 extension. Each subsequent config-backup command increments the numeric extension until the maximum count is reached.

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.

The no form of this command reverts the configuration to the default value.

Default

5

Parameters
count

Specifies the maximum number of backup revisions.

Values

1 to 9

contact
Syntax

contact contact-name

no contact

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command creates a text string that identifies the contact name for the device.

Only one contact can be configured, if multiple contacts are configured the last one entered will overwrite the previous entry.

The no form of this command reverts to the default.

Parameters
contact-name

Specifies the contact name character string. The string may be up to 80 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

coordinates
Syntax

coordinates coordinates

no coordinates

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command creates a text string that identifies the system coordinates for the device location. For example, the command coordinates "37.390 -122.0550" is read as latitude 37.390 north and longitude 122.0550 west.

Only one set of coordinates can be configured. If multiple coordinates are configured, the last one entered overwrites the previous entry.

The no form of this command reverts to the default value.

Parameters
coordinates

Specifies the coordinates describing the device location character string. The string may be up to 80 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. If the coordinates are subsequently used by an algorithm that locates the exact position of this node then the string must match the requirements of the algorithm.

dhcp6
Syntax

dhcp6

Context

config>system

Platforms

7210 SAS-Mxp and 7210 SAS-Sx/S 1/10GE (standalone)

Description

Commands in this context configure system-wide DHCPv6 parameters.

snooping-enable
Syntax

[no] snooping-enable

Context

config>system>dhcp6

Platforms

7210 SAS-Mxp and 7210 SAS-Sx/S 1/10GE (standalone)

Description

This command enables DHCPv6 snooping in a VPLS service at the per-node level to allow the software to appropriately allocate resources to process DHCPv6 messages received on the node. To enable DHCPv6 snooping at the individual service-object level, the user must first configure this command to enable DHCPv6 snooping at the per-node level.

When this command is enabled, the software intercepts both DHCPv4 and DHCPv6 messages received by the node and sends them to the CPU for further processing. If the service object (for example, SAPs and SDP bindings) has DHCPv4 and DHCPv6 snooping enabled, the software adds and removes options to the received DHCPv4 and DHCPv6 client messages.

If this command is enabled and DHCPv4 snooping is disabled at the service object level, the software continues to intercept DHCPv4 messages received by the node and sends them to the CPU to be forwarded as-is without any processing to add or remove options. Similarly, if the command is enabled and DHCPv6 snooping is disabled at the service object level, the software continues to intercept DHCPv6 messages received by the node and sends them to the CPU to be forwarded as-is without any processing to add or remove options.

If this command is not enabled, DHCPv6 snooping does not function and enabling DHCPv6 snooping at the service object level has no effect.

Default

no snooping-enable

ip
Syntax

ip

Context

config>system

Platforms

7210 SAS-Mxp

Description

Commands in this context configure system-wide IP router parameters.

allow-cpu-fragmentation
Syntax

[no] allow-cpu-fragmentation

Context

config>system>ip

Platforms

7210 SAS-Mxp

Description

This command enables CPU-based IP fragmentation. When allow-cpu-fragmentation is enabled, the CPM extracts oversized IPv4 packets from the datapath, fragments them using the system CPU, and inserts the fragmented packets back into the datapath. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Router Configuration Guide for more information about IP fragmentation.

The no form of this command disables CPU-based IP fragmentation.

Default

no allow-cpu-fragmentation

lacp-system-priority
Syntax

lacp-system-priority lacp-system-priority

no lacp-system-priority

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures the Link Aggregation Control Protocol (LACP) system priority on aggregated Ethernet interfaces. LACP allows the operator to aggregate multiple physical interfaces to form one logical interface.

Default

32768

Parameters
lacp-system-priority

Specifies the LACP system priority.

Values

1 to 65535

location
Syntax

location location

no location

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command creates a text string that identifies the system location for the device.

Only one location can be configured. If multiple locations are configured, the last one entered overwrites the previous entry.

The no form of this command reverts to the default value.

Parameters
location

Specifies the location as a character string. The string may be up to 80 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

login-control
Syntax

login-control

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

Commands in this context configure login control.

name
Syntax

name system-name

no name

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command creates a system name string for the device.

For example, system-name parameter ALA-1 for the name command configures the device name as ALA-1.

Only one system name can be configured. If multiple system names are configured, the last one encountered overwrites the previous entry.

The no form of this command reverts to the default value.

Default

the default system name is set to the chassis serial number which is read from the backplane EEPROM

Parameters
system-name

Specifies the system name as a character string. The string may be up to 32 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

oper-group
Syntax

oper-group name [create]

no oper-group name

Context

config>system

Platforms

7210 SAS-T (access-uplink), 7210 SAS-Sx/S 1/10GE (standalone), and 7210 SAS-Sx 10/100GE (standalone)

Description

This command creates a system-wide group name that is used to associate of service objects (for example, ports). The status of the group is derived from the status of its members. The group status can then be used to influence the status of non-member objects. For example, when a group status is marked as down, the objects that monitor the group change their status accordingly.

The no form of this command removes the group. All object associations must be removed before running the no oper-group command.

Default

no oper-group

Parameters
name

Specifies the operational group identifier, up to 32 characters.

create

Keyword to create the configuration context. Once the context is created, it is possible to navigate into the context without the create keyword.

hold-time
Syntax

hold-time

Context

config>system>oper-group

Platforms

7210 SAS-T (access-uplink), 7210 SAS-Sx/S 1/10GE (standalone), and 7210 SAS-Sx 10/100GE (standalone)

Description

Commands in this context configure hold time information.

group-down
Syntax

group-down time in seconds

no group-down

Context

config>system>oper-group>hold-time

Platforms

7210 SAS-T (access-uplink), 7210 SAS-Sx/S 1/10GE (standalone), and 7210 SAS-Sx 10/100GE (standalone)

Description

This command configures the wait time (in seconds) before notifying clients monitoring this group when the oper-group operational status transitions from down to up. A value of zero indicates that transitions are reported immediately to monitoring clients.

The no form of this command reverts the value to the default.

Default

group-down 0

Parameters
time in seconds

Specifies the time, in seconds.

Values

0 to 3600

group-up
Syntax

group-up time in seconds

no group-up

Context

config>system>oper-group>hold-time

Platforms

7210 SAS-T (access-uplink), 7210 SAS-Sx/S 1/10GE (standalone), and 7210 SAS-Sx 10/100GE (standalone)

Description

This command configures the wait time (in seconds) before notifying clients monitoring this group when the oper-group operational status transitions from up to down.

The no form of this command reverts the value to the default.

Default

group-up 4

Parameters
time in seconds

Specifies the time, in seconds.

Values

0 to 3600

vwm-shelf
Syntax

[no] vwm-shelf vwm-shelf-id [create]

Context

config>system

Platforms

7210 SAS-R6 and 7210 SAS-R12

Description

Commands in this context configure the shelf information for 1830 VWM clip-on device.

The user must create the VWM clip-on device and provision the shelf ID to allow the 7210 SAS software to communicate with the shelf and retrieve information. The value specified in the vwm-shelf-id parameter must match the shelf ID set using the rotary dial on the clip-on device. If these shelf IDs do not match, the 7210 SAS devices will not be able to interact to the device and does not provide any information about the device. The software cannot detect a mismatch between the value of the configured vwm-shelf-id and the shelf ID set on the rotary dial.

In prior releases, the software allows user to configure only a single clip-on device for management by specifying a single shelf ID. The software does not allow for configuration of more than a single clip-on shelf.

A fixed number of 1830 VWM devices can be managed by the 7210 SAS devices. The limit depends on the interface used to connect to the 1830 device. The user must provision all the shelves that are connected to the 7210 SAS device.

The no form of this command removes the configured shelf ID and the software removes all the information it has for the shelf.

Parameters
vwm-shelf-id

Specifies the 1830 VWM clip-on device attached to a 7210 SAS device.

Values

1 to 7

Note:

The vwm-shelf-id can take values in the range 1 to 7. This implies that the rotary switch on the connected optical clip-on device must be set to a value in this range.

create

Keyword to create the shelf ID.

vwm-shelf
Syntax

[no] vwm-shelf vwm-shelf-id [vwm-type vwm-type] [create]

Context

config>system

Platforms

7210 SAS-T (network and access-uplink) and 7210 SAS-Mxp

Description

Commands in this context configure the shelf information for 1830 VWM clip-on device.

The user must create the VWM clip-on device and provision the shelf ID to allow the 7210 SAS software to communicate with the shelf and retrieve information. The value specified in the vwm-shelf-id parameter must match the shelf ID set using the rotary dial on the clip-on device. If these shelf IDs do not match, the 7210 SAS devices will not be able to interact to the device and does not provide any information about the device. 7210 SAS software cannot detect a mismatch between the value of the configured vwm-shelf-id and the shelf ID set on the rotary dial.

A fixed number of 1830 VWM devices can be managed by the 7210 SAS devices. The limit depends on the interface used to connect to the 1830 device. The user must provision all the shelves that are connected to the 7210 SAS device.

The vmw-type enables the context to configure the shelf type information for 1830 VWM clip-on device. The user must provision the shelf-type of the connected 1830 device. The software uses this information to match with the shelf-type retrieved from the device and raise a trap/event when there is a mismatch and marks the shelf as operationally down. Additionally, in a cascaded configuration, if there is a mismatch in provisioning of the shelf, the 7210 SAS does not attempt to retrieve information of the shelves that follow the mis-configured shelf.

The no form of this command removes the configured shelf ID and the software removes all the information it has for the shelf.

Parameters
vwm-shelf-id

Specifies the 1830 VWM clip-on device attached to 7210 SAS device.

Values

1 to 7

vwm-type

Specifies the shelf type information for 1830 VWM clip-on device.

Values

ec-cw, ec-dw, ec-dwa

ec-cw

Specifies the controller card to be of type passive 1830 VWM CWDM controller.

ec-dw

Specifies the controller type to be passive 1830 VWM DWDM controller.

ec-dwa

Specifies the controller type to be active 1830 VWM DWDM controller.

Note:

  • The vwm-shelf-id can take values in the range 1 to 7. This implies that the rotary switch on the connected optical clip-on device must be set to a value in this range.

  • For management of DWDM using the 7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12 through OMC interface, the main shelf (that is, the first shelf) to which the node is connected should have EC-DWA. If connected through OMC interface, the shelf ID can be 1 to 7 and if connected through USB interface, the shelf ID should be 0.

  • If the main shelf has any other shelf ID (that is, 1 to 7), the shelf will not become operational.

create

Keyword to create the vwm-shelf-id.

card
Syntax

card card-id

Context

config>system>vwm-shelf

Platforms

7210 SAS-T (network and access-uplink), 7210 SAS-Mxp, 7210 SAS-R6 and 7210 SAS-R12

Description

Commands in this context provision the information for the modules that can be plugged into the slots on the 1830 VWM clip-on device.

This command provides the user better control over the modules plugged into the 1830 CWDM device slots. The user can preprovision acceptable modules by configuring the card-type parameter with the appropriate vwm-acronym. Modules are identified using the card type acronyms listed in Card type acronyms for 1830 CWDM devices and Card type acronyms for 1830 DWDM devices.

The no form of this command removes the configured card ID and the software forgets all the information it has for the card. The software will not raise any events/traps/alarms for the card and clear all pending events/traps/alarms/LEDs.

Parameters
card-id

Specifies the card on the 1830 VWM clip-on device attached to 7210 SAS. Card ID 1 identifies the module in slot #1 of the 1830 CWDM device and Card ID 2 identifies the module in slot #2 of the 1830 CWDM device.

Values

1, 2

shutdown
Syntax

[no] shutdown

Context

config>system>vwm-shelf

Platforms

7210 SAS-T (network and access-uplink), 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

Description

This command administratively disables the management of the clip-on device identified by the parameter vwm-shelf-id. When this command is executed, the software will clear all pending events/traps/alarms related to this shelf.

The no form of this command administratively enables the management of the clip-on device. The software raises appropriate events/traps/alarms for the device.

Default

no shutdown

card-type
Syntax

[no] card-type card-type

Context

config>system>vwm-shelf>card

Platforms

7210 SAS-T (network and access-uplink), 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

Description

This command provides the user a better control over the modules plugged into the 1830 CWDM device slots. The user can preprovision acceptable modules by configuring the card-type parameter with the appropriate card-type vwm-acronym. The modules are identified using the acronyms listed below.

The 7210 SAS validates the configured card-types with the card-type acronym retrieved from the clip-on device and checks the following.

  • If the configured card-type matches the card type acronym retrieved from the clip-on device, the 7210 SAS allows management of the module.

  • If the configured card-type does not match the card type acronym retrieved from the clip-on device, the 7210 SAS raises an event to alert the user of mismatch in configuration. The event results in a major alarm with the major LED set. In such a case, the card status displays ‟Provisioning Mismatch” error.

  • The mismatch event/trap is cleared if the module is replaced with the one that has a correct card type acronym. Any pending trap/event, major alarm and major LED is cleared.

If the user set the card to administratively up and the module is missing, the 7210 SAS raises an event/trap. The event results in a major alarm with the major LED set to the appropriate color. If the user has preprovisioned the card and administratively shut it down, the software does not attempt to match the module’s identifier (if the module is equipped in the slot) and clears any pending alarms. The software retrieves any information about the equipped module to aid the user with provisioning.

The no form of this command removes and clears the card-type information. Until the card-type is provisioned, the software does not raise any events/traps/alarms for the card and clears all pending events/traps/alarms/LEDs.

The following table lists the acronyms defined by the optical group. For more information, see the Product overview guide for 1830 VWM. This is used to preprovision the acceptable modules that can be equipped in the slots of the clip-on device.

Table 15. Card type acronyms for 1830 CWDM devices

Module description

Acronym

1830 VWM 1-CH CWDM FILTER (AB VARIANT) - CH1 (1471nm)

SFC1A

1830 VWM 1-CH CWDM FILTER (AC VARIANT) - CH1 (1491nm)

SFC1B

1830 VWM 1-CH CWDM FILTER (AD VARIANT) - CH1 (1511nm)

SFC1C

1830 VWM 1-CH CWDM FILTER (AE VARIANT) - CH1 (1531nm)

SFC1D

1830 VWM 1-CH CWDM FILTER (AF VARIANT) - CH1 (1551nm)

SFC1E

1830 VWM 1-CH CWDM FILTER (AG VARIANT) - CH1 (1571nm)

SFC1F

1830 VWM 1-CH CWDM FILTER (AH VARIANT) - CH1 (1591nm)

SFC1G

1830 VWM 1-CH CWDM FILTER (AI VARIANT) - CH1 (1611nm)

SFC1H

1830 VWM 2-CH CWDM FILTER (AK VARIANT) - CH1,2

SFC2A&B

1830 VWM 2-CH CWDM FILTER (AL VARIANT) – CH3,4

SFC2C&D

1830 VWM 2-CH CWDM FILTER (AM VARIANT) – CH5,6

SFC2E&F

1830 VWM 2-CH CWDM FILTER (AN VARIANT) – CH7,8

SFC2G&H

1830 VWM 4-CH CWDM FILTER (AP VARIANT) - CH1,2,3,4

SFC4A-D

1830 VWM 4-CH CWDM FILTER (AP VARIANT) – CH5,6,7,8

SFC4E-H

1830 VWM 8-CH CWDM FILTER (AA VARIANT) - CH1,2,3,4,5,6,7,8

SFC8

Table 16. Card type acronyms for 1830 DWDM devices

Module description

Acronym

1830VWM Fan Unit (AA variant)

FANCLIP

Inventory Extension Module

INVMOD

1830VWM EC-DW (AA variant)

EC-DW

1830VWM EC-DW Active (AA variant)

EC-DWA

Remote Filer Modules

1830VWM Remote Filter 8CH (AA VAR)

SFD8A_R

1830VWM Remote Filter 8CH (AB Var)

SFD8B_R

1830VWM Remote Filter 8CH (AC Var)

SFD8C_R

1830VWM Remote Filter 8CH (AD Var)

SFD8D_R

1830VWM Remote Filter 4CH (AE Var)

SFD4A_R

1830VWM Remote Filter 4CH (AF Var)

SFD4B_R

1830VWM Remote Filter 4CH (AG Var)

SFD4C_R

1830VWM Remote Filter 4CH (AH Var)

SFD4D_R

1830VWM Remote Filter 4CH (AJ Var)

SFD4E_R

1830VWM Remote Filter 4CH (AK Var)

SFD4F_R

1830VWM Remote Filter 4CH (AL Var)

SFD4G_R

1830VWM Remote Filter 4CH (AM Var)

SFD4H_R

1830VWM Remote Filter 2CH (AN Var)

SFD2A_R

1830VWM Remote Filter 2CH (AP Var)

SFD2B_R

1830VWM Remote Filter 2CH (AQ Var)

SFD2C_R

1830VWM Remote Filter 2CH (AR Var)

SFD2D_R

1830VWM Remote Filter 2CH (AS Var)

SFD2E_R

1830VWM Remote Filter 2CH (AT Var)

SFD2F_R

1830VWM Remote Filter 2CH (AU Var)

SFD2G_R

1830VWM Remote Filter 2CH (AV Var)

SFD2H_R

1830VWM Remote Filter 2CH (AW Var)

SFD2I_R

1830VWM Remote Filter 2CH (AZ Var)

SFD2L_R

1830VWM Remote Filter 2CH (BA Var)

SFD2M_R

1830VWM Remote Filter 2CH (BB Var)

SFD2N_R

1830VWM Remote Filter 2CH (BC Var)

SFD2O_R

1830VWM Remote Filter 2CH (BD Var)

SFD2P_R

1830 VWM SSY SFD Automatic

2CH (BC Var)

SFD2Q_R

1830 VWM SSY SFD Automatic

2CH (BD Var)

SFD2R_R

DWDM Filters with manual control

1830VWM Manual Filter 8CH (AAVar)

SFD8A

1830VWM Manual Filter 8CH (AB Var)

SFD8B

1830VWM Manual Filter 8CH (AC Var)

SFD8C

1830VWM Manual Filter 8CH (AD Var)

SFD8D

1830VWM Manual Filter 4CH (AE Var)

SFD4A

1830VWM Manual Filter 4CH (AF Var)

SFD4B

1830VWM Manual Filter 4CH (AG Var)

SFD4C

1830VWM Manual Filter 4CH (AH Var)

SFD4D

1830VWM Manual Filter 4CH (AJ Var)

SFD4E

1830VWM Manual Filter 4CH (AK Var)

SFD4F

1830VWM Manual Filter 4CH (AL Var)

SFD4G

1830VWM Manual Filter 4CH (AM Var)

SFD4H

1830VWM Manual Filter 2CH (AN Var)

SFD2A

1830VWM Manual Filter 2CH (AP Var)

SFD2B

1830VWM Manual Filter 2CH (AQ Var)

SFD2C

1830VWM Manual Filter 2CH (AR Var)

SFD2D

1830VWM Manual Filter 2CH (AS Var)

SFD2E

1830VWM Manual Filter 2CH (AT Var)

SFD2F

1830VWM Manual Filter 2CH (AU Var)

SFD2G

1830VWM Manual Filter 2CH (AV Var)

SFD2H

1830VWM Manual Filter 2CH (AWVar)

SFD2I

1830VWM Manual Filter 2CH (AX Var)

SFD2L

1830VWM Manual Filter 2CH (AY Var)

SFD2M

1830VWM Manual Filter 2CH (AZ Var)

SFD2N

1830VWM Manual Filter 2CH (BAVar)

SFD2O

1830VWM Manual Filter 2CH (BB Var)

SFD2P

1830VWM Manual Filter 2CH (BC Var)

SFD2Q

1830VWM Manual Filter 2CH (BD Var)

SFD2R

Amplifier Modules

1830 VWM Fixed Gain Ampl (AAVar)

EALPFG

Parameters
card-type

Specifies an identifier used to match the configured slot module with the equipped slot module. The preceding tables provides the list of acronyms that can be used to identify the supported modules usable with the clip-on device.

Values

SFC1A, SFC1B, SFC1C, SFC1D, SFC1E, SFC1F, SFC1G, SFC1H, SFC2A&B, SFC2C&D, SFC2E&F, SFC2G&H, SFC4A-D, SFC4E-H, SFC8 (CWDM) ANY, EALPFG SFD8A_R, SFD8B_R, SFD8C_R, SFD8D_R, SFD4A_R, SFD4B_R, SFD4C_R, SFD4D_R, SFD4E_R, SFD4F_R, SFD4G_R, SFD4H_R, SFD2A_R, SFD2B_R, SFD2C_R, SFD2D_R, SFD2E_R, SFD2F_R, SFD2G_R, SFD2H_R,SFD2I_R, SFD2L_R, SFD2M_R, SFD2N_R, SFD2O_R, SFD2P_R, SFD2Q_R, SFD2R_R, SFD8A, SFD8B, SFD8C, SFD8D, SFD4A, SFD4B, SFD4C, SFD4D, SFD4E, SFD4F, SFD4G, SFD4H, SFD2A, SFD2B, SFD2C, SFD2D, SFD2E, SFD2F, SFD2G, SFD2H, SFD2I, SFD2L, SFD2M, SFD2N, SFD2O, SFD2P, SFD2Q, SFD2R (DWDM) ascii-string — Can use ASCII alphabets or numbers. Valid card-type acronyms are listed in the Card type acronyms for 1830 DWDM devices.

shutdown
Syntax

[no] shutdown

Context

config>system>vwm-shelf>card

Platforms

7210 SAS-T (network and access-uplink), 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

Description

This command allows the user to administratively disable the management of a specific module inserted in a slot on the clip-on device. When this command is executed, the 7210 SAS software clears all pending events/traps/alarms/LED related to this card.

The no form of this command allows the user to administratively enable the management of the card on the clip-on device. The software raises appropriate events/traps/alarms for the card.

Default

no shutdown

Virtual Chassis (VC) configuration commands
vc-stack
Syntax

vc-stack

Context

config>system

Platforms

7210 SAS-Sx 1/10GE: standalone-VC and 7210 SAS-S 1/10GE: standalone-VC

Description

Commands in this context configure VC parameters.

vc-stack-node
Syntax

vc-stack-node slot-number mac-address mac-address [create]

no vc-stack-node slot-number

Context

config>system>vc-stack

Platforms

7210 SAS-Sx 1/10GE (standalone-VC) and 7210 SAS-S 1/10GE (standalone-VC)

Description

This command configures an IMM-only node in a virtual chassis (VC) configuration. This command is performed on the active CPM node in the VC to which the IMM-only node belongs.

An IMM-only node in a VC is identified by its slot-number and its MAC address. The slot number assigned to the node can be an arbitrary number from 1 to 8. It is used in service provisioning to identify ports on a VC member node, and on service objects on those ports. The port on a VC member node is identified using the format slot-id/1/port-id. For example, port 20 on the front panel of a VC member node in slot 4 is identified as 4/1/20; SAPs configured on those ports are identified as 4/1/20:300.

Slot numbers are unique to each VC which are identified by their vc-stack-node, and can be reused across different VCs. The software ensures the uniqueness of the slot number in each VC by raising an error if two nodes in the same VC are assigned the same slot number.

The MAC address used for VC configuration is the chassis MAC address printed on the label of the node. The MAC address of the IMM-only node is also visible using the console connection.

When an IMM-only node boots up, it uses the MAC address and slot number received in the VC discovery messages sent by the CPM node so that it can boot up in VC mode.

The no form of this command removes the IMM-node from the VC.

Parameters
slot-number

Specifies the slot assigned to an IMM-only node in a VC.

Values

1 to 8

create

Keyword to create the node in a VC.

mac-address

Specifies the chassis MAC address of the IMM-only node.

vc-stack-mac-addr
Syntax

vc-stack-mac-addr mac-address

no vc-stack-node

Context

config>system>vc-stack

Platforms

7210 SAS-Sx 1/10GE (standalone-VC) and 7210 SAS-S 1/10GE (standalone-VC)

Description

This command configures a MAC address for a VC. This command provides an option to assign a MAC address other than the chassis MAC belonging to the CPM-A node. By assigning the MAC address instead of using the chassis MAC address belonging to the CPM-A node, operators do not need to change the MAC address when the CPM-A card is physically replaced with another card.

The no form of this command reverts the value to the default MAC address specified in the BOF.

Parameters
mac-address

Specifies the MAC address of the VC.

System alarm commands
thresholds
Syntax

thresholds

Context

config>system

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

Commands in this context configure monitoring thresholds.

kb-memory-use-alarm
Syntax

kb-memory-use-alarm rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no kb-memory-use-warn

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures memory use, in kilobytes, alarm thresholds.

The no form of this command removes the parameters from the configuration.

Parameters
rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Default

0

Values

–2147483648 to 2147483647

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a falling threshold crossing event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches greater than or equal the rising-threshold value.

Default

0

Values

–2147483648 to 2147483647

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both an entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Values

rising, falling, either

Default

either

kb-memory-use-warn
Syntax

kb-memory-use-warn rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no kb-memory-use-warn

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures memory usage, in kilobytes, for warning thresholds

Parameters
rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Values

–2147483648 to 2147483647

Default

0

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a falling threshold crossing event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches greater than or equal the rising-threshold value.

Values

–2147483648 to 2147483647

Default

0

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds.

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs.

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both an entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Values

rising, falling, either

Default

either

cflash-cap-alarm
Syntax

cflash-cap-alarm cflash-id rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no cflash-cap-alarm cflash-id

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command enables capacity monitoring of the compact flash specified in this command. The severity level is alarm. Both a rising and falling threshold can be specified.

The no form of this command removes the configured compact flash threshold alarm.

Parameters
cflash-id

Specifies the name of the cflash device to be monitored.

Values

cf1:, cf2:, uf1: (7210 SAS-T, 7210 SAS-Sx 1/10GE: standalone and standalone-VC, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp)

cf2:, cf2-A:, cf2-B:, uf1:, uf1-A:, uf1-B: (7210 SAS-R6 and 7210 SAS-R12)

cf1:, cf2: (7210 SAS-S 1/10GE: standalone and standalone-VC)

rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Values

–2147483648 to 2147483647

Default

0

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value raises above this threshold and reaches greater than or equal the rising-threshold value.

Values

–2147483648 to 2147483647

Default

0

interval seconds

Specifies the polling period, in seconds, over which the data is sampled and compared with the rising and falling thresholds.

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both an entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created.

If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated.

If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Default

either

Values

rising, falling, either

cflash-cap-warn
Syntax

cflash-cap-warn cflash-id rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no cflash-cap-warn cflash-id

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command enables capacity monitoring of the compact flash specified in this command. The severity level is warning. Both a rising and falling threshold can be specified.

The no form of this command removes the configured compact flash threshold warning.

Parameters
cflash-id

Specifies the name of the cflash device to be monitored.

Values

cf1:, cf2:, uf1: (7210 SAS-T, 7210 SAS-Sx 1/10GE: standalone and standalone-VC, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp)

cf2:, cf2-A:, cf2-B:, uf1:, uf1-A:, uf1-B: (7210 SAS-R6 and 7210 SAS-R12)

cf1:, cf2: (7210 SAS-S 1/10GE: standalone and standalone-VC)

rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Values

–2147483648 to 2147483647

Default

0

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value raises above this threshold and reaches greater than or equal the rising-threshold value.

Values

–2147483648 to 2147483647

Default

0

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds.

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs.

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both an entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Values

rising, falling, either

Default

either

memory-use-alarm
Syntax

memory-use-alarm rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no memory-use-alarm

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

The memory thresholds are based on monitoring the TIMETRA-SYSTEM-MIB sgiMemoryUsed object. This object contains the amount of memory currently used by the system. The severity level is Alarm. The absolute sample type method is used.

The no form of this command removes the configured memory threshold warning.

Parameters
rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Default

0

Values

–2147483648 to 2147483647

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value raises above this threshold and reaches greater than or equal the rising-threshold value.

Values

–2147483648 to 2147483647

Default

0

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds.

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs.

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds CLI command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both a entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Values

rising, falling, either

Default

either

memory-use-warn
Syntax

memory-use-warn rising-threshold threshold [falling-threshold threshold] interval seconds [rmon-event-type] [startup-alarm alarm-type]

no memory-use-warn

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

The memory thresholds are based on monitoring MemoryUsed object. This object contains the amount of memory currently used by the system. The severity level is Alarm.

The absolute sample type method is used.

The no form of this command removes the configured compact flash threshold warning.

Parameters
rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling-threshold value.

Default

0

Values

–2147483648 to 2147483647

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value raises above this threshold and reaches greater than or equal the rising-threshold value.

Default

0

Values

–2147483648 to 2147483647

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds.

Values

1 to 2147483647

rmon-event-type

Specifies the type of notification action to be taken when this event occurs.

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds CLI command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both a entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value and startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Values

rising, falling, either

Default

either

rmon
Syntax

rmon

Context

config>system>thresholds

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

Commands in this context configure generic RMON alarms and events.

Generic RMON alarms can be created on any SNMP object-ID that is valid for RMON monitoring (for example, an integer-based datatype).

The configuration of an event controls the generation and notification of threshold crossing events configured with the alarm command.

alarm
Syntax

alarm rmon-alarm-id variable-oid oid-string interval seconds [sample-type] [startup-alarm alarm-type] [rising-event rmon-event-id rising-threshold threshold] [falling-event rmon-event-id falling threshold threshold] [owner owner-string]

no alarm rmon-alarm-id

Context

config>system>thresholds>rmon

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures an entry in the RMON-MIB alarm Table. This command controls the monitoring and triggering of threshold crossing events. In order for notification or logging of a threshold crossing event to occur there must be at least one associated rmon>event 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.

The no form of this command removes an rmon-alarm-id from the configuration.

Parameters
rmon-alarm-id

Specifies the alarm being configured. The number of alarms that can be created is limited to 1200.

Values

1 to 65535

variable-oid oid-string

Specifies the variable to be sampled. Only SNMP variables that resolve to an ASN.1 primitive type of integer (integer, Integer32, Counter32, Counter64, Gauge, or TimeTicks) may be sampled. The oid-string may be expressed using either the dotted string notation or as object name plus dotted instance identifier. For example, "1.3.6.1.2.1.2.2.1.10.184582144" or "ifInOctets.184582144".

The oid-string has a maximum length of 255 characters

interval seconds

Specifies the polling period over which the data is sampled and compared with the rising and falling thresholds. In the case of delta type sampling, the interval should be set short enough that the sampled variable is very unlikely to increase or decrease by more than 2147483647 - 1 during a single sampling interval. To avoid creating unnecessary processing overhead, the interval value should not be set too low.

Values

1 to 2147483647

sample-type

Specifies the method of sampling the selected variable and calculating the value to be compared against the thresholds.

Default

absolute

Values

absolute — Specifies that the value of the selected variable will be compared directly with the thresholds at the end of the sampling interval. delta — Specifies that the value of the selected variable at the last sample will be subtracted from the current value, and the difference compared with the thresholds.

startup-alarm alarm-type

Specifies the alarm that may be sent when this alarm is first created. If the first sample is greater than or equal to the rising threshold value an startup-alarm is equal to rising or either, a single rising threshold crossing event is generated. If the first sample is less than or equal to the falling threshold value and startup-alarm is equal to falling or either, a single falling threshold crossing event is generated.

Default

either

Values

rising, falling, either

rising-event rmon-event-id

Specifies the action to be taken when a rising threshold crossing event occurs. If there is no corresponding event configured for the specified rmon-event-id, then no association exists and no action is taken. If the rising-event rmon-event-id has a value of zero (0), no associated event exists.

If a rising-event rmon-event-id is configured, the CLI requires a rising threshold to also be configured.

Default

0

Values

0 to 65535

rising-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold. A single threshold crossing event will also be generated if the first sample taken is greater than or equal to this threshold and the associated startup-alarm is equal to rising or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value falls below this threshold and reaches less than or equal the falling threshold value.

Values

–2147483648 to 2147483647

Default

0

falling-event rmon-event-id

Specifies the action to be taken when a falling threshold crossing event occurs. If there is no corresponding event configured for the specified rmon-event-id, then no association exists and no action is taken. If the falling-event has a value of zero (0), no associated event exists.

If a falling event is configured, the CLI requires a falling-threshold to also be configured.

Values

–2147483648 to 2147483647

Default

0

falling-threshold threshold

Specifies a threshold for the sampled statistic. A single threshold crossing event is generated when the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold. A single threshold crossing event will also be generated if the first sample taken is less than or equal to this threshold and the associated startup-alarm is equal to falling or either.

After a rising threshold crossing event is generated, another such event will not be generated until the sampled value rises above this threshold and reaches greater than or equal the rising-threshold value.

Values

–2147483648 to 2147483647

Default

0

owner owner

Specifies the owner. The owner identifies the creator of this alarm. It defaults to ‟TiMOS CLI”. This parameter is defined primarily to allow entries that have been created in the RMON-MIB alarmTable by remote SNMP managers to be saved and reloaded in a CLI configuration file. The owner will not normally be configured by CLI users and can be a maximum of 80 characters.

Default

TiMOS CLI

event
Syntax

event rmon-event-id [event-type] [description description-string] [owner owner-string]

no event rmon-event-id

Context

config>system>thresholds>rmon

Platforms

Supported on all 7210 SAS platforms as described in this document, including platforms configured in the access-uplink operating mode

Description

This command configures an entry in the RMON-MIB event table. 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 if an entry in the RMON-MIB log table should be created to record the occurrence of the event. It may also specify that an SNMP notification (trap) should be generated for the event. The RMON-MIB defines two notifications for threshold crossing events: Rising Alarm and Falling Alarm.

Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the TiMOS event logs. However, when the event-type is set to trap, the generation of a Rising Alarm or Falling Alarm notification creates an entry in the TiMOS event logs and that is distributed to whatever TiMOS log destinations are configured: CONSOLE, session, memory, file, syslog, or SNMP trap destination.

The TiMOS 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.

This no form of this command removes an rmon-event-id from the configuration.

Parameters
rmon-event-type

Specifies the type of notification action to be taken when this event occurs.

Values

log — An entry is made in the RMON-MIB log table for each event occurrence. This does not create a TiMOS logger entry. The RMON-MIB log table entries can be viewed using the show system thresholds command.

trap — A TiMOS logger event is generated. The TiMOS logger utility then distributes the notification of this event to its configured log destinations which may be CONSOLE, telnet session, memory log, cflash file, syslog, or SNMP trap destinations logs.

both — Both an entry in the RMON-MIB logTable and a TiMOS logger event are generated.

none — No action is taken.

Default

both

description description-string

Specifies a user configurable string that can be used to identify the purpose of this event. This is an optional parameter and can be up to 80 characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

owner owner

Specifies the creator of this alarm. This parameter is defined primarily to allow entries that have been created in the RMON-MIB alarmTable by remote SNMP managers to be saved and reloaded in a CLI configuration file. The owner will not normally be configured by CLI users and can be a maximum of 80 characters.

Default

TiMOS CLI

PTP commands
ptp
Syntax

ptp

Context

config>system

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

Commands in this context configure parameters for IEEE 1588-2008, Precision Time Protocol.

anno-rx-timeout
Syntax

anno-rx-timeout count

no anno-rx-timeout

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the PTP announce receipt timeout count in the Announce message.

Note:

When the G.8275.1 profile is configured, the 7210 SAS supports a count value of 3 only.

The no form of this command reverts the count to the default value.

Default

anno-rx-timeout 3

Parameters
count

Specifies the PTP announce receipt timeout count.

Values

2 to 10

clock
Syntax

clock

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

Commands in this context configure the source of frequency reference for PTP.

freq-source
Syntax

freq-source freq-source

no freq-source

Context

config>system>ptp>clock

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures a stable frequency reference obtained through one of the line references (SyncE or bits) for the PTP clock. This is achieved by specifying ssu to be the frequency source for PTP. This mode of operation where PTP is used only for time recovery, and SyncE or BITS is used for frequency recovery, is known as PTP hybrid mode.

If the frequency reference is set to ssu, PTP is running in hybrid mode (if PTP is also in a no shutdown state) using the recovered frequency provided by the central clock through either of the configured references (SyncE or BITS, whichever is configured as a reference for the central clock). In this setting, PTP cannot be configured as a reference in the ref-order. The CLI blocks this configuration. The reverse is also true; that is, if PTP is configured under ref-order, this parameter cannot be set to ssu.

If the frequency reference is set to ptp, PTP runs in pure mode, potentially being configured as a frequency reference in ref-order.

Note:

See Configuration guidelines and restrictions for PTP for more information about command usage.

The no form of this command reverts to the default value.

Default

freq-source ptp

Parameters
freq-source

Specifies whether PTP is used for frequency and time recovery, or only for time recovery. If ptp is specified, PTP is used for both frequency and time recovery. If ssu is specified, PTP is used only for time recovery.

Values

ptp, ssu

clock-type
Syntax

clock-type boundary

clock-type ordinary slave

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the type of clock. The clock-type can only be changed when PTP is shutdown.

When changing the clock-type to or from a boundary clock on the 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Mxp, and 7210 SAS-T platforms, the node must be rebooted for the change to take effect.

Default

ordinary slave

Parameters
boundary

Keyword to configure the clock as a boundary clock capable of functioning as both a timeTransmitter and timeReceiver concurrently.

ordinary slave

Keyword to configure the clock as an ordinary PTP timeReceiver.

domain
Syntax

domain domain

no domain

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the PTP domain.

The domain cannot be modified unless PTP is shut down.

If the PTP profile is modified, the domain is changed to the default domain for the new PTP profile.

The no form of this command reverts to the default configuration.The default value depends on the configured profile.

Default

0 for ieee1588-2008

4 for g8265dot1-2010

24 for g8275dot1-2014

Parameters
domain

Specifies the PTP domain.

Values

0 to 255 for ieee1588-2008

0 to 255 for g8265dot1-2010

24 to 43 for g8275dot1-2014

local-priority
Syntax

local-priority priority

Context

config>system>ptp

config>system>ptp>peer

config>system>ptp>port

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the local priority used to choose between PTP timeTransmitters in the best timeTransmitter clock algorithm (BTCA). This setting is relevant when the profile is set to g8265dot1-2010 or g8275dot1-2014. The parameter is ignored when the profile is set to ieee1588-2008. The value 1 is the highest priority and 255 is the lowest priority.

For g8265dot1-2010, this command sets the priority to select between timeTransmitter clocks with the same quality.

For g8275dot1-2014, this command sets the value of the localPriority associated with the Announce messages received from the external clocks (ptp>peer or ptp>port), or the local clock (PTP).

Default

local-priority 128

Parameters
priority

Specifies the value of the local priority.

Values

1 to 255

log-anno-interval
Syntax

log-anno-interval log-interval

no log-anno-interval

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the PTP Announce interval.

Note:

When the G.8275.1 profile is configured, the 7210 SAS supports a log-interval value of –3 only. The system automatically changes the value to –3 when this profile is configured.

The no form of this command reverts to the default value.

Default

log-anno-interval 1

Parameters
log-interval

Specifies the PTP Announce interval, specified as the logarithm to the base 2, in seconds.

Values

–3 to 4, where –3 = 0.125 s, –2 = 0.25 s, –1 = 0.5 s, 0 = 1 s, 1 = 2 s, 2 = 4 s, 3 = 8 s, 4 = 16 s

log-sync-interval
Syntax

log-sync-interval values

no log-sync-interval

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the message interval used for transmission of multicast synchronization messages.

This command applies only if the profile is set to ieee1588-2008 or g8265dot1-2010. It does not apply when g8275dot1-2014 is configured. When the profile is set to g8275dot1-2014, the value is set to –4 (16 packets/s) and cannot be changed.

For multicast messages used on PTP Ethernet ports, this command configures the message interval used for synchronization messages transmitted by the local node when the port is in the timeTransmitter state.

The no form of this command reverts the message interval to the default value.

Default

–6 (64 packets/s) for ieee1588-2008

–6 (64 packets/s) for g8265dot1-2010

–4 (16 packets/s) for g8275dot1-2014

Parameters
values

Specifies the message interval, in log form.

Values

–6 to –3, where –6 = 64 packets/s, –5 = 32 packets/s, –4 = 16 packets/s, –3 = 8 packets/s

network-type
Syntax

network-type {sdh | sonet}

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the codeset used to encode the QL values into PTP clockClass values when the profile is configured for G.8265.1. The codeset is defined in G.8265.1, Table 1.

This configuration only applies to the range of values observed in the clockClass values transmitted out of the node in Announce messages. The 7210 SAS supports the reception of any valid value in G.8265.1, Table 1.

This command applies only if the PTP profile is set to g8265dot1-2010.

Default

network-type sdh

Parameters
sdh

Specifies the values used on a G.781 Option 1 compliant network.

sonet

Specifies the values used on a G.781 Option 2 compliant network.

peer
Syntax

peer ip-address [create]

no peer ip-address

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-T (network and access-uplink)

Description

Commands in this context configure parameters associated with remote PTP peers.

Note:

The maximum supported number of PTP peers depends on the supported PTP PPS rate on 7210 SAS platforms. Contact a Nokia representative for more information.

If the clock-type is ordinary slave or boundary, and PTP is not shut down, the last peer cannot be deleted. This prevents the user from having PTP enabled without any peer configured and enabled.

The no form of this command deletes the specified peer.

Parameters
ip-address

Specifies the IPv4 address of the remote peer.

Values

a.b.c.d

create

Keyword to create the peer.

shutdown
Syntax

[no] shutdown

Context

configure>system>ptp>peer

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-T (network and access-uplink)

Description

This command disables or enables a specific PTP peer. Shutting down a peer sends cancel unicast negotiation messages on any established unicast sessions. When the peer is shut down, all received packets from the peer are ignored.

If the clock-type is ordinary slave or boundary, and PTP is not shut down, the last enabled peer cannot be shut down. This prevents the user from having PTP enabled without any peer configured and enabled.

Default

no shutdown

port
Syntax

port port-id [create]

no port port-id

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures PTP over Ethernet on the physical port. The PTP process transmits and receives PTP messages through the port using Ethernet encapsulation (as opposed to UDP/IPv4 encapsulation).

The frames are transmitted with no VLAN tags even if the port is configured for dot1q or qinq modes for encap-type. In addition, the received frames from the external PTP clock must also be untagged.

There are two reserved multicast addresses allocated for PTP messages, as defined in IEEE 1588-2008 Annex F (see the address command for more information). Either address can be configured for the PTP messages sent through this port.

This command applies only if the PTP profile is set to g8275dot1-2014.

Changing the encapsulation or the port type of the Ethernet port is not permitted when PTP Ethernet multicast operation is configured on the port. To change the encapsulation or port type, the physical port must be shut down.

The no form of this command deletes the specified PTP port.

Parameters
port-id

Specifies a physical port.

Values

slot/mda/port

create

Keyword to create the PTP port.

address
Syntax

address {01:1b:19:00:00:00 | 01:80:c2:00:00:0e}

Context

config>system>ptp>port

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the MAC address to be used as the multicast destination MAC address for transmitted PTP messages.

This command applies only if the PTP profile is set to g8275dot1-2014.

The IEEE Std 1588-2008 Annex F defines two reserved addresses for PTP messages:

  • 01-1B-19-00-00-00 — for all messages except peer delay mechanism messages

  • 01-80-C2-00-00-0E — for peer delay mechanism messages

The system accepts PTP messages received using either destination MAC address, regardless of the address configured by this command.

Default

01:1b:19:00:00:00

master-only
Syntax

master-only {true | false}

Context

config>system>ptp>port

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command prevents the local port from ever entering the timeReceiver state. This can be used to ensure that the 7210 SAS never draws synchronization from the attached external device.

This command only applies if the profile is set to g8275dot1-2014.

If the clock-type command is set to ordinary slave, the master-only value is set the false.

Parameters
true

Keyword to prevent the local port from entering the timeReceiver state.

false

Keyword to allow the local port to enter the timeReceiver state or timeTransmitter state.

shutdown
Syntax

[no] shutdown

Context

config>system>ptp>port

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command disables or enables a specific PTP port. When the PTP port is shut down, all PTP Ethernet messages are dropped on the IOM. They are not counted in the PTP message statistics. No PTP packets are transmitted by the node toward this port.

If the clock-type is ordinary slave or boundary, and PTP is not shut down, the last enabled port cannot be shut down. This prevents the user from having PTP enabled without any means to synchronize the local clock to a parent clock.

This command only applies if the profile is set to g8275dot1-2014.

The no form of this command disables the specific PTP port.

Default

no shutdown

Special Cases
PTP Protocol Handling

Applies only to the 7210 SAS-Mxp. When the first instance of the PTP protocol is created and the no shutdown command is issued in the base routing instance, resources are allocated to enable CPU processing of the protocol. The resources are deallocated when the last instance is removed from the configuration using the shutdown command.

priority1
Syntax

priority1 priority-value

no priority1

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the priority1 value of the local clock. This parameter is only used when the profile is set to ieee1588-2008. This value is used by the BTCA to determine which clock should provide timing for the network. It is also used as the advertised value in Announce messages and as the local clock value in data set comparisons.

The no form of this command reverts to the default value.

Default

priority1 128

Parameters
priority-value

Specifies the value of the priority1 field.

Values

0 to 255

priority2
Syntax

priority2 priority-value

no priority2

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the priority2 value of the local clock. This parameter is only used when the profile is set to ieee1588-2008 or g8275dot1-2014. This value is used by the BTCA to determine which clock should provide timing for the network. It is also used as the advertised value in Announce messages and as the local clock value in data set comparisons.

The no form of this command reverts to the default value.

Default

priority2 128

Parameters
priority-value

Specifies the value of the priority2 field.

Values

0 to 255

profile
Syntax

profile {g8265dot1-2010 | ieee1588-2008 | g8275dot1-2014}

Context

config>system>ptp

Platforms

7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE (standalone), 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 (standalone), 7210 SAS-T (network and access-uplink)

Description

This command configures the profile for the internal PTP clock. This profile defines the BTCA behavior.

Note:

The 7210 SAS-Sx 10/100GE 64SFP+ 4QSFP28 supports only the G.8275.1 profile.

The profile cannot be changed unless PTP is shut down.

When the profile is changed, the domain is changed to the default value for the new profile. On some 7210 SAS platforms, a profile change requires a node reboot. See Configuration guidelines and restrictions for PTP for more information.

Descriptions in the config>system>ptp context indicate whether the command is applicable based on the configured profile.

Default

profile g826dot1-2010

Parameters
g8265dot1-2010

Keyword to conform to the ITU-T G.8265.1 specification.

ieee1588-2008

Keyword to conform to the 2008 version of the IEEE 1588 standard.

g8275dot1-2014

Keyword to conform to the ITU-T G.8275.1 specification.

Date and time commands
set-time
Syntax

set-time [date] [time]