System management

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 node’s fully qualified domain name. The system name can be any ASCII printable text string of up to 32 characters.

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 of up to 80 characters.

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

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

Two-dimensional GNSS 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 range 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.

A Common Language Location Identifier (CLLI) code string for the device is an 11-character standardized geographic identifier that uniquely identifies the geographic location of places and specific 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.

A system identifier is a manually configured IPv4 address that can be used to uniquely identify the 7705 SAR in the network in situations where the more commonly used system IP address may change dynamically, causing loss of historical data attributed to the node. For example, the system IP address can change dynamically using DHCP when the 7705 SAR is acting as a DHCP client and the DHCP server-facing interface is unnumbered. In this situation, a static system identifier may be desirable.

The system identifier can be any IPv4 address.

The 7705 SAR-H supports Power over Ethernet (PoE) on all four 10/100/1000 copper Ethernet ports. To use PoE, the PoE power source must be configured at the system level as either internal or external. When the system is configured for the internal PoE power source option, PoE capability can be enabled on ports 5 and 6 only. In addition, port 5 can be enabled for PoE+ but in that case, port 6 cannot support any PoE capability. When the system is configured for the external PoE power source option, a mix of PoE and PoE+ is available on ports 5, 6, 7, and 8. See the 7705 SAR-H Chassis Installation Guide, ‟Ethernet Ports”, for information about supported combinations of PoE and PoE+.

To enable PoE or PoE+ on a PoE-capable port on the 7705 SAR-H, use the config>port>ethernet>poe command;see the 7705 SAR Interface Configuration Guide, ‟Configuration Command Reference”, for more information.

The PoE-capable ports on the 7705 SAR-H act as a Power Source Equipment (PSE) device. They support IEEE 802.3at and IEEE 802.3af.

The 7705 SAR-Wx (variants 3HE07616AA and 3HE07617AA) supports PoE+ on the RJ45 Ethernet port with PoE+. The PoE+ ports are used to deliver power to a ‟Powered Device”, such as a non-line-of-sight (NLOS) or line-of-sight (LOS) microwave radio, at levels compatible with the IEEE 802.3at standard.

To enable PoE+ on a PoE+-capable port on the 7705 SAR-Wx, use the config>port>ethernet>poe plus command; see the 7705 SAR Interface Configuration Guide, ‟Configuration Command Reference”, for more information.

Setting a time zone in the 7705 SAR allows for times to be displayed in the local time instead of in UTC. The 7705 SAR has 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 7705 SAR system-defined time zones are listed in the following table, which includes both time zones with and without summer time correction.

NTP is the Network Time Protocol defined in RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis and RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification. It allows for the participating network nodes to keep time more accurately and maintain time in a more synchronized fashion among all participating network nodes.

NTP uses stratum levels to define the number of hops from a reference clock. The reference clock is considered to be 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 GNSS or atomic clock.

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.

The 7705 SAR runs a single NTP clock that operates NTP message exchanges with external NTP clocks. Exchanges can be made with external NTP clients, servers, and peers. These exchanges can be through the base, management, or VPRN routing instances.

When NTP is enabled, the NTP clock in the 7705 SAR operates as an NTP client by default. The 7705 SAR typically operates as a stratum 2 device, relying on an external stratum 1 server to source accurate time into the network.

Alternatively, the NTP clock in the 7705 SAR can recover time from a local PTP or GNSS source. This is achieved by configuring the PTP clock or GNSS receiver as the internal system time. The internal system time can then be identified as the preferred source of NTP timing into the network with the command config>system>time>ntp>server>system-time>prefer. This configuration makes the local PTP or GNSS source appear as a stratum 0 server. When the internal PTP clock or GNSS is identified as the server for NTP, NTP promotes the internal NTP server (the 7705 SAR) to the stratum 1 level, which may affect the NTP network topology.

The 7705 SAR can also operate as an NTP server and provide timing to downstream clients with the ntp-server command. When the NTP server is enabled with authentication, any NTP clients must authenticate using the correct key.

In server mode, the 7705 SAR advertises the ability to act as a clock source for other network elements. By default, the router transmits NTP packets in NTP version 4 mode. Server mode is supported on the CSM Management port, in the base routing context, and in the VPRN routing context.

As an NTP server, the 7705 SAR can peer with an external NTP server in another router that is considered more trustworthy or accurate than other routers carrying NTP in the system. This allows the peers to act as mutual backups where they can obtain time from or supply time to the other server as required. If both servers are peering each other, the router is in symmetric active mode. This mode requires that the peer association is set on both routers so that the local and remote router designate each other as a peer. If only one server is peering the other (that is, the other peer has not specifically configured the peer association), the router is in symmetric passive mode.

The 7705 SAR can be configured to transmit broadcast NTP packets on a specified interface with the broadcast command. The interface can be the management interface, interfaces in the base routing context, or an interface in the VPRN context. The messages are transmitted using a destination address that is the NTP broadcast address. Only IPv4 addressing is supported.

The 7705 SAR can also be configured to receive broadcast NTP packets on interfaces in the base routing context or on the management interface with the broadcastclient command.

The router can be configured to transmit or receive multicast NTP packets on the CSM Management port. The multicast command configures the transmission of NTP multicast messages. The multicastclient command configures the receipt of multicast NTP packets. When receiving or sending multicast NTP messages, the default address 224.0.1.1 is used. Only IPv4 addressing is supported.

The following NTP elements are supported:

• authentication keys – both DES and MD5 authentication are supported as well as multiple keys, to provide increased security support in carrier and other networks

• server and peer addressing – external servers and external peers may be defined using IPv4 or IPv6 addresses

• 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 router, SNTP transitions to an operationally down state. If NTP is removed from the configuration or shut down, SNTP resumes an operationally up state.

• NTP priority – if a higher-priority time source such as GNSS or PTP is selected on the router, NTP transitions to an operationally down state. If the higher-priority time source is disqualified or disabled, NTP 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) must be performed, the adjustment is performed by programmatically setting the clock. If a minor adjustment (less than 128 ms) must be performed, the adjustment is performed by either speeding up or slowing down the clock.

• to facilitate correct operation when the standby CSM takes over from the active CSM, the time on the secondary CSM must be synchronized with the clock of the active CSM

• to prevent the generation of too many 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 that indicates that event/trap blocking is taking place.

NTP accuracy depends on the accuracy of NTP packet timestamping. By default, NTP packets are timestamped by the CSM where the NTP protocol is executed. However, an enhanced NTP mode is available where the timestamping is performed on the adapter card by the network processor. This reduces variations introduced by packet delay within the router as well as by a busy CPU in the CSM. This enhanced mode is only available for in-band NTP over a network interface. When enhanced NTP mode is used, NTP authentication is not supported.

For synchronizing the system clock with outside time sources, the 7705 SAR includes a Simple Network Time Protocol (SNTP) client. As defined in RFC 2030, SNTP Version 4 is an adaptation of the Network Time Protocol (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.

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

The 7705 SAR SNTP client can be configured for either broadcast or unicast client mode.

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

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.

For more information about PTP, see IEEE 1588v2 PTP.

The 7705 SAR can receive and extract time of day/phase recovery from a 1588 grandmaster clock or boundary clock and transmit the recovered time of day/phase signal to an external device such as a base station through an external time of day port, where available. Transmission is through the ToD or ToD/PPS Out port with a 1 pulse/s output signal. The port interface communicates the exact time of day by the rising edge of the 1 pulse/s signal.

For more information about ToD-1pps, see PTP ordinary timeReceiver clock for time of day/phase recovery.

The 7705 SAR supports frequency synchronization via a Layer 1 interface such as synchronous Ethernet, and ToD synchronization via a protocol such as NTP or PTP. In cases where these methods are not possible, or where accuracy cannot be ensured for the service, you can deploy a GNSS receiver as a synchronous timing source. GNSS data is used to provide network-independent frequency and ToD synchronization.

GNSS receivers on the following platforms support GPS reference only, or combined GPS and GLONASS reference:

• 7705 SAR-Ax

• 7705 SAR-H with a GPS Receiver module

• 7705 SAR-Wx variants with a GPS RF port

• 7705 SAR-8 Shelf V2 with a GNSS Receiver card

• 7705 SAR-18 with a GNSS Receiver card

A 7705 SAR chassis equipped with a GNSS receiver and an attached GNSS antenna can be configured to receive frequency traceable to stratum 1 (PRC/PRS). The GNSS receiver provides a synchronization clock to the SSU in the router with the corresponding QL for SSM. This frequency can then be distributed to the rest of the router from the SSU as configured with the ref-order and ql-selection commands. The GNSS reference is qualified only if the GNSS receiver is operational, has five or more satellites locked, and has a frequency successfully recovered. A PTP timeTransmitter or boundary clock can also use this frequency reference with PTP peers.

In the event of GNSS signal loss or jamming resulting in the unavailability of timing information, the GNSS receiver automatically prevents output of clock or synchronization data to the system, and the system can revert to alternate timing sources.

On the 7705 SAR, the CRON feature supports periodic and date- and time-based scheduling. CRON is used, for example, to schedule Service Assurance Agent (SAA) functions. CRON functions include specifying scripts that need to be run and when they are to be scheduled. Reboots, peer turn-ups, and SAA tests are scheduled with CRON, as well as OAM events such as connectivity checks or troubleshooting runs.

CRON supports the schedule function. The schedule function is used to configure the type of schedule to run, including one-time-only (one-shot), periodic, or calendar-based runs. All runs are scheduled by month, day, hour, minute, and interval (seconds).

Scripts that have been configured under the config>system>script-control context are referenced by the CRON schedule. For information about scripts, see CLI script control.

The following redundancy features enable the duplication of data elements and software functionality to maintain service continuation in case of outages or component failure.

With NSR on the 7705 SAR, 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 such that routing topology and reachability are not affected, even in the presence of routing updates. NSR achieves high availability through parallelization by maintaining up-to-date routing state information, at all times, on the standby route processor. This capability is achieved independently of protocols or protocol extensions, providing a more robust solution than graceful restart protocols between network routers.

The NSR implementation on the 7705 SAR applies to all supported routing protocols. NSR makes it possible to keep the existing sessions (such as LDP) during a CSM switchover, including support for MPLS signaling protocols. Peers do not see any change.

Traditionally, high availability issues have been patched through non-stop forwarding solutions. NSR overcomes these limitations by delivering an intelligent hitless failover solution.

The following NSR entities remain intact after a switchover:

• ATM/IMA VPs/VCs

• LDP

• PPP and MLPPP sessions

• RIP neighbors

In-service upgrades allow new routing engine software and microcode to be installed on the 7705 SAR while existing services continue to operate. Software upgrades can be performed only for specific maintenance releases (generally R4 loads and higher). Software upgrades also require NSR. If software or microcode on the CSM needs to be upgraded, CSM redundancy is required.

Follow the steps below to upgrade routing engine software on the 7705 SAR without affecting existing services:

1. Install new software on the standby CSM.

2. Reboot the standby CSM for the new software to take effect.

3. Perform a manual switchover on the active CSM by using the force-switchover command on the CLI. The standby CSM becomes the active CSM, placing the formerly active CSM into standby.

4. Repeat steps 1 and 2 to upgrade the standby CSM.

During a switchover, system control and routing protocol execution are transferred from the active to the standby CSM. A switchover may occur automatically or manually.

An automatic switchover may occur under the following conditions:

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

• the active CSM is declared down (not responding)

• online removal of the active CSM

Users can manually force the switchover from the active CSM to the standby CSM by using the admin redundancy force-switchover now CLI command or the admin reboot active [now] CLI command.

With the 7705 SAR, the admin reboot active [now] CLI command does not cause both CSMs to reboot.

Synchronization between the CSMs includes the following:

• Configuration and boot-env synchronization

• State database synchronization

Whenever configuration changes are made, the modified configuration must be saved so that it is not lost when the system is rebooted.

Configuration files are saved by executing explicit command syntax that includes the file URL location to save the configuration file as well as options to save both default and non-default configuration parameters. Boot options file (BOF) parameters specify where the system should search for configuration and image files as well as other operational parameters during system initialization.

For more information about the BOF, see the chapter on Boot options in this guide.

Two post-boot configuration extension files are supported and are triggered when either a successful or failed boot configuration file is processed. The boot-bad-exec and boot-good-exec commands specify URLs 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.

For example, after a configuration file is successfully loaded, the specified URL can contain a nearly identical configuration file with specific commands enabled or disabled, or particular parameters specified and according to the script which loads that file.

The boot-env option enables a synchronization of all the files used in system initialization.

When configuring the system to perform this synchronization, the following occurs:

1. The BOF used during system initialization is copied to the same compact flash on the standby CSM (in redundant systems).

   Note: The synchronization parameters on the standby CSM are preserved.

2. The primary, secondary, and tertiary images (provided they are locally stored on the active CSM) are copied to the same compact flash on the standby CSM.

3. The primary, secondary, and tertiary configuration files (provided they are locally stored on the active CSM) are copied to the same compact flash on the standby CSM.

The config option synchronizes configuration files by copying the files specified in the active CSM BOF file to the same compact flash on the standby CSM.

The force-switchover now command forces an immediate switchover to the standby CSM card.

If the active and standby CSMs are not synchronized for some reason, users can manually synchronize the standby CSM by rebooting the standby by issuing the admin reboot standby command on the active CSM.

There are five potential ACR states:

• normal

• phase tracking

• frequency tracking

• holdover

• free-run

When a port’s ACR state is normal, phase tracking, or frequency tracking, the recovered ACR clock is considered a qualified reference source for the SSU. If this reference source is being used, then transitions between any of these three states do not affect SSU operation.

When a port’s ACR state is free-run or holdover, the recovered ACR clock is disqualified as a reference source for the SSU. If this reference source is being used, then transitions to either of these two states cause the SSU to drop the reference and switch to the next highest prioritized reference source. This can potentially be SSU holdover.

The system collects statistics on all ACR-capable ports. ACR statistics detail how the digital phase locked loop (DPLL) is functioning in one or more ACR instances in the adapter card. ACR statistics assist with isolating a problem during degraded synchronization performance or with anticipating future issues.

Within the DPLL, there are two values that contribute to ACR statistics:

• DCO frequency

• input phase error of each 2-second update interval

The DCO is the digitally controlled oscillator that produces the regenerated clock signal. The input phase error is the correction signal that provides feedback to the DPLL to tune the DCO output. The input phase error should approach zero as the DPLL locks in to the source timing information and stabilizes the output.

The continuous 2-second updates to the output DCO frequency are directly applied as the clock output of the ACR instance. ACR statistics allow you to view the mean frequency and the standard deviation of the output DCO frequency.

During every 2-second update interval, the input phase error and the output DCO frequency are recorded. The input phase error mean, input phase error standard deviation, output DCO mean (Hz and ppb), and output DCO standard deviation are calculated every 60 seconds.

Entering a show CLI command on a port with ACR displays the mean and standard deviation values for the previous 60-second interval. A show detail command on the same port displays the previous 15 sets of 60-second intervals and a list of state and event counts. An SNMP MIB is also available with these statistics.

Each DS1, E1, DS3, or E3 circuit configured with DCR executes its own clock recovery from the packet stream. This allows each circuit to have an independent frequency.

The following table lists the supported timestamp frequencies for each platform and adapter card.

The timestamp frequency is configured at the adapter card level and is used by all DCR ports or channels on the supporting platforms and cards. Both ends of a TDM pseudowire using DCR must be running the same frequency. If a network contains different types of equipment using DCR, a common frequency must be selected that is supported by all equipment.

DCR complies with published jitter and wander specifications (G.823, G.824, and G.8261) for traffic interfaces under typical network conditions and for synchronous interfaces under specified packet network delay, loss, and delay variance (jitter) conditions.

Each timeTransmitter clock has its own configuration for IP address, packet rate, and messaging timeouts, and for statistics, alarms, and events. Each available timeTransmitter clock advertises its presence and information using Announce messages. If both timeTransmitter clocks are available, the timeReceiver clock uses the best timeTransmitter clock algorithm (BTCA) to dynamically compare the information in the Announce messages of each timeTransmitter clock to determine to which of the two timeTransmitter clocks it should synchronize. This timeTransmitter clock is known as the best timeTransmitter. After the timeReceiver clock has determined which is the best timeTransmitter, it can begin to negotiate with it for unicast synchronization communication.

The configured setting for the profile command determines the precedence order for selecting the best timeTransmitter clock algorithm. The 7705 SAR supports the following profile settings: ieee1588-2008, itu-telecom-freq, g8275dot1-2014, g8275dot2-2016, iec-61850-9-3-2016, and c37dot238-2017. For information about the g8275dot1-2014 and g8275dot2-2016 profile parameters, see ITU-T G.8275.1 and G.8275.2. For information about the iec-61850-9-3-2016 and c37dot238-2017 profile parameters, see IEC/IEEE 61850-9-3 and C37.238-2017.

If the profile setting for the clock is ieee1588-2008, iec-61850-9-3-2016, or c37dot238-2017, the precedence order for the best timeTransmitter selection algorithm is as follows:

• priority1 (user-configurable on the timeTransmitter clock side)

• clock class

• clock accuracy

• PTP variance (offsetScaledLogVariance)

• priority2 (user-configurable on the timeTransmitter clock side)

• clock identity

• distance (number of boundary clocks)

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

• clock class

• peer ID

If the profile setting for the clock is g8275dot1-2014 or g8275dot2-2016, the precedence order for the best timeTransmitter selection algorithm is as follows if the grandmaster clock is connected to a primary reference time clock (PRTC) in locked mode:

• clock class

• clock accuracy

• PTP variance (offsetScaledLogVariance)

• priority2 (user-configurable on the timeTransmitter clock side)

• localPriority

• steps removed from the grandmaster

• port identities

• port numbers

If the profile setting for the clock is g8275dot1-2014 or g8275dot2-2016, the precedence order for the best timeTransmitter selection algorithm is as follows if the grandmaster clock is in holdover and out of holdover specification, or is without a time reference since startup:

• clock class

• clock accuracy

• PTP variance (offsetScaledLogVariance)

• priority2 (user-configurable on the timeTransmitter clock side)

• localPriority

• clock identity

• steps removed from the grandmaster

• port identities

• port numbers

The following figure shows an example of the messaging sequence between the PTP timeReceiver clock and the two PTP timeTransmitter clocks.

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 UDP/IP or Ethernet and can be unicast (for IP) or multicast (for Ethernet). For UDP/IP, both IPv4 and IPv6 unicast mode with unicast negotiation is supported.

As part of the basic synchronization timing computation, a number of 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, with the two-step operation requiring a follow-up message after each synchronization message. Currently, only one-step operation is supported when the 7705 SAR is a timeTransmitter clock; PTP frequency and time can be recovered from both one-step and two-step operation when the 7705 SAR is acting as a timeReceiver or boundary clock.

For IPv4, the two-step operation is optional. For IPv6, the two-step operation is a mandatory requirement for the 7705 SAR.

In one-step operation, a timestamp is inserted in the synchronization message when the packet is transmitted to the timeReceiver clock. In two-step operation, the timestamp is sent in the follow-up message. If the timestamp is changed in the synchronization message, the checksum field is recomputed. Because the checksum field is a mandatory field for IPv6 (optional for IPv4), the 7705 SAR requires the timestamp to be sent separately to avoid potential checksum corruption in the packet.

During startup, the PTP timeReceiver clock receives the 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 basic synchronization timing computation between the PTP timeReceiver clock and PTP best timeTransmitter is illustrated in the following figure. This figure illustrates the offset of the timeReceiver clock referenced to the best timeTransmitter signal during startup.

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.

The performance objective is to meet the synchronization interface maximum time interval error (MTIE) mask. Similar to ACR, the number of factors with the PSN contributes to how well PTP can withstand, and still meet, those requirements.

PTP messages are supported via IPv4 unicast with a fixed IP header size or via IPv6.

PTP messaging is supported on network interfaces. If a node loopback address is used as the source interface for 1588 packets, the packets can ingress any network IP interface on the router. If the source interface is associated with a physical port, packets must be sent to the interface on that port.

PTP messaging is also supported on IES interfaces for access ports.

The 7705 SAR can also forward IPv4-encapsulated PTP messages over BGP-LU routes for frequency synchronization. The following profiles are supported for these messages: ieee1588-2008, itu-telecom-freq, and g8275dot2-2016.

The following table describes the supported message rates for timeReceiver and timeTransmitter states for IP-encapsulated PTP traffic, based on the profile configured. The ordinary clock can be either in the timeReceiver or timeTransmitter state. The boundary clock can be in both of these states.

Note:

1. In the timeTransmitter clock state, the minimum rate granted is 1 per 16 seconds if requested by the timeReceiver clock.

See Rates for Ethernet-encapsulated PTP messages for the supported message rates for Ethernet-encapsulated PTP traffic.

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

The PTP algorithm is able to recover the clock using both the upstream and downstream directions in both ordinary timeReceiver and boundary clock modes. The ability to perform bidirectional recovery improves the performance of networks where the upstream and downstream load is not symmetrical.

The Bell Labs algorithm looks at the PTP packet exchange in both directions between the timeTransmitter and timeReceiver. There can be more packet delay variation in one direction if there is a high utilization rate or congestion in that direction. The algorithm assesses the stability and reliability of the packet exchange in each direction and assigns weight values based on the results. The system gives preference to frequency synchronization from the direction with a higher weight value. The weight values change dynamically and can be viewed with detailed PTP show commands.

The PTP ordinary clock with timeReceiver capability on the 7705 SAR provides an 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.

The PTP timeReceiver capability is implemented on the Ethernet ports of the platforms listed in IEEE 1588v2 PTP support per fixed platform and on the cards listed in IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18 .

The 7705 SAR-8 Shelf V2 can support up to six timeReceiver clocks and the 7705 SAR-18 can support up to eight timeReceiver clocks.

All other fixed platforms listed in IEEE 1588v2 PTP support per fixed platform can support up to two PTP clocks when one of those clock types is configured as transparent; otherwise, they support only one timeReceiver clock.

Each timeReceiver clock can provide a separate frequency reference to the SSU.

The following figure shows the operation of an ordinary PTP clock in timeReceiver mode.

Each PTP ordinary timeReceiver clock is configured for a specific slot where the card or Ethernet port performs the timeReceiver function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on the 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each timeReceiver is also associated with an IP interface on a specific port, adapter card, or loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a timeReceiver clock.

For best performance, the network should be designed so that the IP messaging between the timeTransmitter clock and the timeReceiver clock ingresses and egresses through a port where the timeReceiver is configured. If the ingress and egress flow of the PTP messages is via a different port or adapter card on the 7705 SAR, then the packets are routed through the fabric to the Ethernet card with the PTP timeReceiver.

It is possible that the PTP IP packets may be routed through another Ethernet port/VLAN, OC3/STM1 or OC12/STM4 clear channel POS, OC3/STM1 or OC12/STM4 channelized MLPPP, DS3/E3 PPP, or DS1/E1 MLPPP. The PTP timeReceiver performance may be slightly worse in this case because of the extra PDV experienced through the fabric. Packets are routed this way only if the clock is configured with a loopback address. If the clock is configured with an address tied to a physical port, the packets arrive on that physical port as described above.

The 7705 SAR supports the PTP ordinary clock in timeTransmitter mode. Normally, a 1588v2 grandmaster is used to support many timeReceivers and boundary clocks in the network. In cases where only a small number of timeReceivers and boundary clocks exist and only frequency is required, a PTP integrated timeTransmitter clock can greatly reduce hardware and management costs to implement PTP across the network. It also provides an opportunity to achieve better performance by placing a timeTransmitter clock deeper into the network, as close to the timeReceiver clocks as possible.

The following figure shows a PTP timeTransmitter clock network configuration.

The PTP timeTransmitter clock capability is implemented on the Ethernet ports of the platforms listed in IEEE 1588v2 PTP support per fixed platform and on the cards listed in IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18 .

The 7705 SAR-8 Shelf V2 can support up to six timeTransmitter clocks and the 7705 SAR-18 can support up to eight timeTransmitter clocks. The fixed platforms listed in IEEE 1588v2 PTP support per fixed platform can each support one timeTransmitter clock.

The following figure shows the operation of an ordinary PTP clock in timeTransmitter mode.

Each PTP timeTransmitter clock is configured for a specific slot where the card or Ethernet port performs the timeTransmitter function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on a 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each timeTransmitter is also associated with an IP interface on a specific port, adapter card, or loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a timeTransmitter clock. All packets that ingress or egress through a port where the timeTransmitter is configured are routed to their destination via the best route as determined in the route table.

Each timeTransmitter clock can peer with up to 50 timeReceivers or boundary clocks. The IP addresses of these peers can be statically configured via CLI or dynamically accepted via PTP signaling messages. A statically configured peer may displace a dynamic peer on a particular PTP port. If there are fewer than 50 peers, then that dynamic peer can signal back and be granted a different PTP port instance.

The 7705 SAR supports boundary clock PTP devices in both timeTransmitter and timeReceiver states. IEEE 1588v2 can function across a packet network that is not PTP-aware; however, the performance may be unsatisfactory and unpredictable. PDV across the packet network varies with the number of hops, link speeds, usage rates, and the inherent behavior of the 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 specific 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 clocks) or boundary clocks. The following figure shows the operation of a boundary clock.

The PTP boundary clock capability is implemented on the Ethernet ports of the platforms listed in IEEE 1588v2 PTP support per fixed platform and on the cards listed in IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18 .

The 7705 SAR-8 Shelf V2 can support up to six boundary clocks and the 7705 SAR-18 can support up to eight boundary clocks. The fixed platforms listed in IEEE 1588v2 PTP support per fixed platform can each support one boundary clock.

Each PTP boundary clock is configured for a specific slot where the card or Ethernet port performs the boundary clock function. On the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, and 7705 SAR-Wx, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. When the 7705 SAR-M is receiving PTP packets on a 2-port 10GigE (Ethernet) module, its PTP clock continues to use slot 1/1. Each boundary clock is also associated with a loopback address for the router; however, the IP interface configured on a 2-port 10GigE (Ethernet) module cannot be associated with a boundary clock.

Each boundary clock can be peered with up to 50 timeReceivers, boundary clocks, or grandmaster clocks. The IP addresses of these peers can be statically configured via CLI or dynamically accepted via PTP signaling messages. A statically configured peer may displace a dynamic peer on a particular PTP port. If there are fewer than 50 peers, that dynamic peer can signal back and be granted a different PTP port instance.

The following figure shows an example of boundary clock operation.

The following equipment supports PTP timeReceiver clock for time of day/phase recovery:

• all fixed platforms listed in IEEE 1588v2 PTP support per fixed platform

• all cards listed in IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18

The 7705 SAR can receive and extract time of day/phase recovery from a 1588 grandmaster clock or boundary clock and transmit the recovered time of day/phase signal to an external device such as a base station through an external time of day port, where available. The PTP timeReceiver clock can be used as a reference for the router system time clock, providing high-accuracy OAM timestamping and measurements for the 7705 SAR chassis.

On the 7705 SAR-8 Shelf V2 CSMv2, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-M, and 7705 SAR-X, transmission is through the ToD port with a 1 pulse/s output signal that is phase-aligned with other routers that are similarly time of day/phase synchronized. An RS-422 serial interface within the ToD port connector communicates the exact time of day of the rising edge of the 1 pulse/s signal. The serial interface on the ToD out port and the ToD in port on the CSMv2 are currently not supported; therefore, the 7705 SAR-8 Shelf V2 does not support Time of Day messages.

On the 7705 SAR-H, transmission is through the IRIG-B Out port. An RJ45 interface is used for the IRIG-B Out port to communicate the exact time of day by the rising edge of the 1 pulse/s signal, an IRIG-B000 unmodulated time code signal, and an IRIG-B12X modulated time code signal.

On the 7705 SAR-H, the Time of Day message output is only available when the router is configured with an active IP PTP timeReceiver clock or boundary clock. For all other routers, the Time of Day message output is available when the router is configured with an active IP PTP timeReceiver clock or boundary clock or when Time of Day is recovered from an Ethernet PTP clock or integrated GNSS.

The following table lists the 1 pulse/s signal (1pps) support and Time of Day messaging support per platform.

The following table describes the format of the ToD message.

Note:

1. Enhanced ToD 1pps values are not supported on the 7705 SAR-H.

For incoming IEEE 1588 packets, the destination IP address is the 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-Wx, or 7705 SAR-X loopback address. The ingress interface can be an SFP Ethernet port on the faceplate of the chassis, an RJ45 port on the faceplate of the chassis, or a port on an installed module.

Each PTP timeReceiver clock can be configured to receive timing from up to two PTP timeTransmitter clocks in the network. If both timeTransmitter clocks are available, the timeReceiver clock uses default BTCA to determine which of the two timeTransmitter clocks it should synchronize.

PTP messaging between the PTP timeTransmitter clock and PTP timeReceiver clock is done over UDP/IP using IPv4 unicast mode with a fixed IP header size or using IPv6. Unicast negotiation is supported. Each PTP instance supports up to 128 synchronization messages per second.

PTP recovered time accuracy depends on the delay of the forward path and the reverse path being symmetrical. It is possible to correct for known path delay asymmetry by using the ptp-asymmetry command for PTP packets destined for the local timeReceiver clock or downstream PTP timeReceiver clock.

The following equipment supports PTP boundary clock capability for time of day/phase recovery:

• all fixed platforms listed in IEEE 1588v2 PTP support per fixed platform

• all cards listed in IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18

The 7705 SAR-8 Shelf V2 can support up to six boundary clocks and the 7705 SAR-18 can support up to eight boundary clocks. The fixed platforms can each support one boundary clock. PTP boundary clocks that recover time of day/phase from a grandmaster clock or another boundary clock can be used as a reference for the router system time clock, providing high-accuracy OAM timestamping and measurements for the 7705 SAR chassis.

Each PTP boundary clock for time of day/phase is configured for a specific slot where the adapter card or port performs the boundary clock function. On fixed platforms, with the exception of the 7705 SAR-X, this slot is always 1/1. On the 7705 SAR-X, this slot is always either 1/2 or 1/3. Each boundary clock is also associated with a loopback or system address for the router.

PTP end-to-end transparent clock for time of day/phase recovery is supported on the following:

• the fixed platforms listed in IEEE 1588v2 PTP support per fixed platform

• 2-port 10GigE (Ethernet) module

Transparent clock functionality is supported for PTP packets over UDP/IP over Ethernet (with and without VLAN tags).

For high-accuracy 1588 PTP clock recovery, timestamping of incoming and outgoing messages should be done as close to ingress and egress as possible when the 7705 SAR is acting as a 1588 transparent clock. Edge timestamping is performed on all packets from all Ethernet ports, including SFP and RJ45 ports on the faceplate of the chassis or a port on an installed module.

PTP recovered time accuracy depends on the delay of the forward path and the reverse path being symmetrical. It is possible to correct for known path delay asymmetry by using the ptp-asymmetry command to configure an asymmetry delay setting in nanoseconds per direction for each edge.

To enable transparent clock processing at the node level, configure a PTP clock with the transparent-e2e clock type (using the clock-type command). Deconfiguring such a PTP clock disables transparent clock processing.

PTP timeTransmitter clock capability for time of day/phase distribution is implemented on the following platforms:

• 7705 SAR-H with a GPS Receiver module

• 7705 SAR-Wx variants with a GPS RF port

• 7705 SAR-8 Shelf V2 with a GNSS Receiver card

• 7705 SAR-18 with a GNSS Receiver card

Time of day input must be enabled using the use-node-time command before the node can be used as a PTP grandmaster clock. GNSS must also be the active system time reference for nodes that are being used as a grandmaster clock. When the use-node-time command is enabled, the PTP timeTransmitter clock uses the system time as a source of PTP time and can be used for time of day/phase distribution. When the use-node-time command is disabled, the PTP timeTransmitter clock can be used for frequency only.

Each PTP timeReceiver clock can be configured to receive timing from up to two PTP timeTransmitter clocks. If two PTP timeTransmitter clocks are configured, and if communication to the best timeTransmitter is lost or if the BTCA determines that the other PTP timeTransmitter clock is better, then the PTP timeReceiver clock switches to the other PTP timeTransmitter clock.

For a redundant or simple CSM configuration on the 7705 SAR-8 Shelf V2 and 7705 SAR-18, a maximum of two PTP timeReceiver clocks can be configured as the source of reference (ref1 and ref2) to the SSU. If a failure occurs between the PTP timeReceiver clock and the timeTransmitter clock, the SSU detects that ref1 or ref2 is unavailable and automatically switches to the other reference source. This switching provides PTP hot redundancy for hardware failures (on the 6-port Ethernet 10Gbps Adapter card, 8-port Gigabit Ethernet Adapter card, 10-port 1GigE/1-port 10GigE X-Adapter card, or Packet Microwave Adapter card) or port or facility failures (SFP or cut fiber). If a loopback address is used, PTP packets may arrive on any router network interface and the PTP clock remains up.

The 7705 SAR-M, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-Wx, and 7705 SAR-X support only one PTP timeReceiver clock. This timeReceiver clock can be configured as the source of reference (ref1 or ref2) to the SSU.

The 7705 SAR can be configured to transmit and receive PTP messages over a port that uses Ethernet encapsulation. The encapsulation type can be null, dot1q, or qinq. Ethernet-encapsulated PTP messages are processed on the node CSM or CSM functional block, and they are supported on ordinary timeReceiver, ordinary timeTransmitter, or boundary clocks for either frequency or time of day/phase recovery. The 7705 SAR-Ax can also support a grandmaster clock. The 7705 SAR-H, 7705 SAR-Wx, 7705 SAR-8 Shelf V2, and 7705 SAR-18 can also support a grandmaster clock when equipped to support GNSS. A PTP clock using Ethernet encapsulation can support up to 50 external peer clocks.

All platforms and cards that support PTP functionality support Ethernet-encapsulated PTP messages, except for the 2-port 10GigE (Ethernet) Adapter card/module. See IEEE 1588v2 PTP support per fixed platform and IEEE 1588v2 PTP support per card on the 7705 SAR-8 Shelf V2 and 7705 SAR-18 for a complete list of supported platforms and cards.

Ethernet encapsulation is configured on a per-port basis using the config>system> ptp>clock command, with the clock-id parameter set to csm. Ports can simultaneously support IPv4-encapsulated or IPv6-encapsulated PTP messages and Ethernet-encapsulated PTP messages. As well, the 7705 SAR supports the interworking of a PTP timeReceiver using IPv4-encapsulated or IPv6-encapsulated messages with a PTP timeTransmitter using Ethernet-encapsulated messages.

When a PTP clock is configured for Ethernet encapsulation, the following profiles are available:

• ieee1588-2008

• g8275dot1-2014

• iec-61850-9-3-2016

• c37dot238-2017

The following table describes the supported message rates for timeReceiver and timeTransmitter states for Ethernet-encapsulated PTP traffic, based on the profile configured. The ordinary clock can be either in the timeReceiver or timeTransmitter state. The boundary clock can be in both of these states.

See Rates for IP-encapsulated PTP messages for the supported message rates for IP-encapsulated PTP traffic.

PTP messages are transported within Ethernet frames with the Ethertype set to 0X88F7. Ports can be configured with one of two reserved multicast destination addresses:

• 01-1B-19-00-00-00 – used for all PTP messages except for peer delay mechanism messages

• 01-80-C2-00-00-0E – used for peer delay mechanism messages

Either address can be used for all messages depending on customer requirements. See Recommendation ITU-T G.8275.1/Y.1369.1. When the profile configuration is iec-61850-9-3-2016 or c37dot238-2017, the 01-80-C2-00-00-0E address must be used for peer delay. See IEC/IEEE 61850-9-3 and the C37.238-2017 extension.

When the profile configuration is ieee1588-2008, iec-61850-9-3-2016, or c37dot238-2017, the PTP clock’s priority1 and priority2 settings are used by the BTCA to help determine which clock should provide timing for the network. When the profile configuration is g8275dot1-2014, the local-priority value is used to choose between PTP timeTransmitters in the BTCA.

The 7705 SAR supports Recommendation ITU-T G.8275.1 and Recommendation ITU-T G.8275.2, which specify the architecture that allows the distribution of time and phasing. ITU-T G.8275.1 supports full timing support from the network and ITU G.8275.2 supports partial timing support (PTS) and assisted partial timing support (APTS). If a PTP clock is configured for G.8275.2 without GNSS, it uses PTS; if it is configured for GNSS, it can use APTS. It is assumed that these profiles will be used in well-planned cases where network behavior and performance can be constrained within well-defined limits, including limits on static asymmetry. When configured for the G.8275.1 or G.8275.2 profile, the 7705 SAR can operate as a boundary clock, an ordinary timeTransmitter clock, or an ordinary timeReceiver clock.

When the 7705 SAR is configured for the G.8275.1 or G.8275.2 profile, it uses an alternate BTCA for best timeTransmitter clock selection. This BTCA includes a PTP dataset comparison that is defined in IEEE 1588-2008, but with the following differences:

• the priority1 attribute value is removed from the dataset comparison

• the master-only parameter value must be considered

• multiple active grandmaster clocks are allowed; therefore, the BTCA will select the nearest clock of equal quality

• a port-level local-priority attribute value is used to select a timeReceiver port if two ports receive an Announce message. This attribute is used as a tiebreaker in the dataset comparison algorithm if all other previous attributes of the datasets being compared are equal.

• the local-priority parameter value is considered for the default dataset

The ITU-T G.8275.1 and G.8275.2 profiles have the following characteristics:

• The default domain setting is 24 for G.8275.1; the allowed range is 0 to 255.

  The default domain setting is 44 for G.8275.2; the allowed range is 0 to 255.

• Both one-step and two-step clocks are supported on timeReceiver-capable PTP ports.

• G.8275.2 supports IP encapsulation.

  G.8275.1 supports IP encapsulation and Ethernet encapsulation. When Ethernet encapsulation is used, the following points apply:

  • Ethernet multicast addressing is used for transmitting PTP messages. Both the non-forwardable multicast address 01-80-C2-00-00-0E and forwardable multicast address 01-1B-19-00-00-00 are supported.

  • Virtual local area network (VLAN) tags within Ethernet frames carrying PTP messages are not supported. When a PTP clock receives a PTP message within a frame containing a VLAN tag, it discards this frame. A PTP clock that is compliant with the profile described in Recommendation ITU-T G.8275.1 must comply with IEEE 1588 – 2008 Annex F.

• Synchronization messages are sent at a rate of 16 packets/s; Announce messages are sent at a rate of 8 packets/s.

• On the 7705 SAR, the priority1 value is set to the default value (128) and cannot be changed.

• On the 7705 SAR, if the clock-type parameter is set to ordinary slave, the priority2 value is set to the default value (255) and cannot be changed.

For further details, see Recommendation ITU-T G.8275.1/Y.1369.1 and Recommendation ITU-T G.8275.2/Y.1369.2.

The 7705 SAR supports IEC/IEEE 61850-9-3 and the C37.238-2017 extension, which are profiles that allow PTP to act as a timing source in power utility networks.

The IEC/IEEE 61850-9-3 and C37.238-2017 profiles support only Ethernet encapsulation with multicast addressing. Both profiles use the peer delay mechanism instead of the delay-request/response mechanism.

When configured for IEC/IEEE 61850-9-3 or C37.238-2017, the 7705 SAR can operate as a grandmaster clock, a boundary clock, or an ordinary timeReceiver clock and supports recovery of frequency as well as time of day/phase. Grandmaster clock functionality is only available for 7705 SAR variants with integrated GNSS.

Synchronous Ethernet can be used for frequency recovery as an optional mode for best time/phase recovery.

The IEC/IEEE 61850-9-3 and C37.238-2017 profiles have the following characteristics.

• The default domain setting is 0 for IEC/IEEE 61850-9-3 and 254 for C37.238-2017; the allowed range is 0 to 255.

• One-step clock operation is supported, without the need for follow-up messages.

• When Ethernet encapsulation is used, virtual local area network (VLAN) tags within Ethernet frames carrying PTP messages are not supported. When a PTP clock receives a PTP message within a frame containing a VLAN tag, it discards this frame.

• Synchronization messages, Announce messages, and peer delay messages are sent, by default, at the rate of 1 packet/s.

• By default, the priority1 and priority2 values are set to 255 when the clock type is ordinary timeReceiver and 128 when the clock type is ordinary timeTransmitter. The priority values can be configured to be between 0 and 255.

The C37.238-2017 profile uses the IEEE_C37_238 TLV in Announce messages between the parent and timeReceiver clocks. This TLV includes the grandmaster clock ID and the total time inaccuracy. Each clock in the chain adds its own inaccuracy to the total time inaccuracy, which gives the ultimate timeReceiver clock an estimate of the inaccuracy over the entire path.

The grandmaster inaccuracy includes the source time inaccuracy and the grandmaster time inaccuracy. When acting as a boundary clock, the system receives the total time inaccuracy from the parent clock and adds its own time inaccuracy, then sends out a TLV with the updated total time inaccuracy. By default, the time inaccuracy value is 100 ns for a grandmaster clock and 50 ns for a boundary clock. The default value can be changed for a boundary clock with the time-inaccuracy-override command.

For further details, see the IEC/IEEE 61850-9-3 standard and the C37.238-2017 extension.

The PTP profile interworking feature allows the 7705 SAR to interwork a primary PTP profile with ports using alternate profiles connected to external devices. The 7705 SAR supports single-clock and multi-clock PTP profile interworking.

The 7705 SAR provides the capability to collect statistics, state, and events data for the PTP timeReceiver clock’s interaction with PTP peer clock 1 and PTP peer clock 2. This data is collected separately for each peer clock and can be displayed using the show system ptp clock ptp-port command. This data can be used to monitor the PTP timeReceiver clock performance in relation to the peer clocks and to diagnose a problem or analyze the performance of a packet switched network for the transport of synchronization messages. The following data is collected:

PTP peer-1/PTP peer-2 statistics:

• number of signaling packets

• number of unicast request announce packets

• number of unicast request announce timeouts

• number of unicast request announce packets rejected

• number of unicast request synchronization packets

• number of unicast request synchronization timeouts

• number of unicast request synchronization packets rejected

• number of unicast request delay response packets

• number of unicast request delay response packets timeouts

• number of unicast request delay response packets rejected

• number of unicast grant announce packets

• number of unicast grant announce packets rejected

• number of unicast grant synchronization packets

• number of unicast grant synchronization packets rejected

• number of unicast grant delay response packets

• number of unicast grant delay response packets rejected

• number of unicast cancel announce packets

• number of unicast cancel synchronization packets

• number of unicast cancel delay response packets

• number of unicast acknowledge cancel announce packets

• number of unicast acknowledge cancel synchronization packets

• number of unicast acknowledge cancel delay response packets

• number of announce packets

• number of synchronization packets

• number of follow-up packets

• number of delay response packets

• number of delay request packets

• number of out-of-order synchronization packets

• total number of UDP (port 320) packets

• total number of UDP (port 319) packets

• number of alternate timeTransmitter packets discarded

• number of bad domain packets discarded

• number of bad version packets discarded

• number of duplicate messages packets discarded

• number of step RM greater than 255 discarded

PTP timeTransmitter-1/PTP timeTransmitter-2 algorithm state statistics (in seconds):

• number of free-run states

• number of acquiring states

• number of phase-tracking states

• number of hold-over states

• number of locked states

PTP timeTransmitter-1/PTP timeTransmitter-2 algorithm event statistics:

• number of excessive frequency errors detected

• number of excessive packet losses detected

• number of packet losses spotted

• number of excessive phase shifts detected

• number of high PDVs detected

• number of synchronization packet gaps detected

The 7705 SAR supports the collection of performance monitoring statistics for the time recovery algorithm based on IEEE 1588-2019, Annex J. Use the show > system > ptp clock > performance-monitoring command to view the statistics. The following table describes the record index values.

Each record includes the average, minimum, maximum, and standard deviation values for the following statistics:

• offset-from-master
• mean-path-delay
• timeTransmitter-to-timeReceiver delay (master-to-slave-delay)
• timeReceiver-to-timeTransmitter delay (slave-to-master-delay)

For a SONET/SDH interface, a BITS DS1 or E1 physical port, a DS1 or E1 port interface that supports SSM, or a synchronous Ethernet interface that supports ESMC, a timing input provides a quality level value to indicate the source of timing of the far-end transmitter. These values provide input to the selection processes on the nodal timing subsystem. This selection process determines which input to use to generate the signal on the SSM egress ports and the reference to use to synchronize the nodal clock:

• For the two reference inputs (ref1 and ref2) and for the BITS input ports, if the interface configuration supports the reception of a QL over SSM or ESMC, then the quality level value is associated with the timing derived from that input.

• For the two reference inputs and for the BITS input ports, if the interface configuration is T1 with SF framing, then the quality level associated with the input is QL-UNKNOWN.

• For the two reference inputs, if they are synchronous Ethernet ports and the ESMC is disabled, then the quality level value associated with that input is QL-UNKNOWN.

• For the two reference inputs and for the BITS input ports, if the interface configuration supports the reception of a QL over SSM (and not ESMC), and no SSM value has been received, then the quality level value associated with the input is QL-STU.

• For the two reference inputs and for the BITS input ports, if the interface configuration supports the reception of a QL over SSM or ESMC, but the quality level value received over the interface is not valid for the type of interface, then the quality level value associated with that input is QL-INVALID.

• For the two reference inputs, if they are external synchronization, DS3, or E3 ports, then the quality level value associated with the input is QL-UNKNOWN.

• For the two reference inputs, if they are synchronous Ethernet ports and the ESMC is enabled but no valid ESMC Information PDU has been received within the previous 5 s, then the quality level value associated with that input is QL-FAILED.

• If the user has configured an override for the quality level associated with an input, the node displays both the received and override quality level value for the input. If no value has been received, then the associated value is displayed instead.

After the quality level values have been associated with the system timing inputs, the two reference inputs and the external input timing ports are processed by the system timing module to select a source for the SSU. This selection process is described below.

• Before an input can be used as a potential timing source, it must be enabled using the ql-selection command. If ql-selection is disabled, then the priority order of the inputs for the Synchronous Equipment Timing Generator (SETG) is the priority order configured under the ref-order command.

• If ql-selection is enabled, then the priority of the inputs is calculated using the associated quality level value of the input and the priority order configured under the ref-order command. The inputs are ordered by the internal relative quality level (shown in the middle row in Quality level (QL) values by interface type (SDH, SONET, SyncE) ) based on their associated quality level values. If two or more inputs have the same quality level value, then they are placed in order based on where they appear in the ref-order priority. The priority order for the SETG is based on both the reference inputs and the external synchronization input ports.

• When a prioritized list of inputs is calculated, the SETG and the external synchronization output ports are configured to use the inputs in their respective orders.

• When the SETG and external synchronization output ports priority lists are programmed, then the highest-qualified priority input is used. To be qualified, the signal is monitored to ensure that it has the expected format and that its frequency is within the pull-in range of the SETG.

General system parameters include:

• Name

• Contact

• Location

• CLLI code

• Coordinates

• System identifier

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.

Time elements include:

• Zone

• Summer time conditions

• NTP

• SNTP

• PTP

• Time-of-day measurement (ToD-1pps)

• GNSS

• CRON

Use the following CLI syntax to configure system time elements. The authentication-key des keyword is not supported if the 7705 SAR node is running in FIPS-140-2 mode.

CLI syntax:

config>system
time
    dst-zone zone-name
        end {end-week} {end-day} {end-month} [hours-minutes]
        offset offset
        start {start-week} {start-day} {start-month} [hours-minutes]
    gnss
        port port-id time-ref-priority priority-value
    ntp
        authentication-check 
        authentication-key key-id {key key} [hash | hash2] {type des | message-digest}
        broadcastclient [router router-name] {interface ip-int-name} [authenticate]
        mda-timestamp
        multicastclient [authenticate]
        server {ip-address | ipv6-address} [key-id key-id] [version version] [prefer]
        no shutdown
    ptp
        clock clock-id time-ref-priority priority-value
        clock csm time-ref-priority priority-value
    sntp
        broadcast-client
        server-address ip-address [version version-number] [normal | preferred] [interval seconds]
        no shutdown
    tod1-pps
        message-type {ct | cm | irig-b002-b122 | irig-b003-b123 | irig-b006-b126 | irig-b007-b127}
    zone {std-zone-name | non-std-zone-name} [hh[:mm]] 

The switchover-exec command specifies the location and name of the CLI script file executed following a redundancy switchover from the previously active CSM card.

CLI syntax:

config>system
    switchover-exec file-url

Automatic synchronization can be configured in the config>system> synchronization context.

Manual synchronization can be configured with the following command:

CLI syntax:

admin
    redundancy
        synchronize {boot-env | config}

Example:

admin>redundancy# synchronize config

The following shows the output that displays during a manual synchronization:

ALU-1>admin>redundancy# synchronize config 

Syncing configuration......

Syncing configuration.....Completed.
ALU-1# 

The force-switchover now command forces an immediate switchover to the standby CSM card.

CLI syntax:

admin
    redundancy
        force-switchover [now]

Example:

admin>redundancy# force-switchover now

ALU-1# admin redundancy force-switchover now
ALU-1y#
Resetting...
?

If the active and standby CSMs are not synchronized for some reason, users can manually synchronize the standby CSM by rebooting the standby by issuing the admin reboot standby command on the active or the standby CSM.

Network operators can specify the type of synchronization operation to perform between the primary and secondary CSMs after a change has been made to the configuration files or the boot environment information contained in the BOF.

Use the following CLI command to configure the boot-env option:

CLI syntax:

config
    redundancy
        synchronize {boot-env | config}

Example:

config>redundancy# synchronize boot-env

The following displays the configuration:

*ALU-1>config>redundancy# synchronize boot-env
*ALU-1>config>redundancy# show redundancy synchronization
===============================================================================
Synchronization Information
===============================================================================
Standby Status               : disabled
Last Standby Failure         : N/A
Standby Up Time              : N/A
Failover Time                : N/A
Failover Reason              : N/A
Boot/Config Sync Mode        : Boot Environment
Boot/Config Sync Status      : No synchronization
Last Config File Sync Time   : Never
Last Boot Env Sync Time      : Never
===============================================================================

Use the following CLI command to configure the config option:

CLI syntax:

config
    redundancy
        synchronize {boot-env | config}

Example:

config>redundancy# synchronize config

The following example displays the configuration.

ALU-1>config>redundancy# synchronize config
ALU-1>config>redundancy# show redundancy synchronization
===================================================
Synchronization Information
===================================================
Synchronize Mode        : Configuration
Synchronize Status      : No synchronization
Last Config Sync Time   : 2006/06/27 09:17:15
Last Boot Env Sync Time : 2006/06/24 07:16:37
===================================================

When configuring multi-chassis redundancy, configuration must be performed on the two nodes that forms redundant-pair peer nodes. Each node points to its peer using the peer command.

When creating a multi-chassis LAG, the LAG must first be created under the config>lag lag-id context. Additionally, the LAG must be in access mode and LACP must be enabled (active or passive). Under the multi-chassis>peer>mc-lag context, the lag-id is the ID of the previously created LAG.

Use the following CLI syntax to configure multi-chassis redundancy features:

CLI syntax:

config>redundancy
    multi-chassis
       peer ip-address
            authentication-key [authentication-key | hash-key] [hash | hash2]
           description description-string
           mc-lag
           hold-on-neighbor-failure multiplier
           keep-alive-interval interval
           lag lag-id lacp-key admin-key system-id system-id [remote-lag lag-id] system-priority system-priority
        no shutdown 
        source-address ip-address 

Example:

config>redundancy# 
config>redundancy# multi-chassis
config>redundancy>multi-chassis# peer 10.10.10.2 create
config>redundancy>multi-chassis>peer# description ‟Mc-Lag peer 10.10.10.2”
config>redundancy>multi-chassis>peer# mc-lag
config>redundancy>mc>peer>mc-lag# lag 1 lacp-key 32666 system-id 00:00:00:33:33:33 system-priority 32888
config>redundancy>mc>peer>mc-lag# no shutdown
config>redundancy>mc>peer>mc-lag# exit
config>redundancy>multi-chassis>peer# no shutdown
config>redundancy>multi-chassis>peer# exit
config>redundancy>multi-chassis# exit
config>redundancy#

The following displays the configuration:

A:7705:Dut-A>config>redundancy# info
----------------------------------------------
            multi-chassis
                peer 10.10.10.2 create
                   description "Mc-Lag peer 10.10.10.2"
                    mc-lag
                       lag 1 lacp-key 32666 system-id 00:00:00:33:33:33 system
priority 32888
                       no shutdown
                    exit
                    no shutdown
                exit
            exit
----------------------------------------------
A:7705:Dut-A>config>redundancy#

The disconnect command immediately disconnects a user from a console, Telnet, FTP, SSH, SFTP, or MPT craft terminal (MCT) session.

The ssh keyword disconnects users connected to the node via SSH or SFTP.

CLI syntax:

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

Example:

admin# disconnect 

The following example displays the disconnect command results.

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

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

CLI syntax:

admin
    set-time date time

Example:

admin# set-time 2010/09/24 14:10:00

The following example displays the set-time command results.

     ALU-1# admin set-time 2010/09/24 14:10:00
     ALU-1# show time
     Fri Sept 24 14:10:25 UTC 2010
     ALU-1#

The display-config command displays the system’s running configuration.

CLI syntax:

admin
    display-config [detail] [index]

Example:

admin# display-config detail

The following example displays a portion of the display-config detail command results.

ALU-1>admin# display-config detail
# TiMOS-B-0.0.current both/i386 NOKIA SAR 7705 
# Copyright (c) 2016 Nokia.
# All rights reserved. All use subject to applicable license agreements.
# Built on Fri Sept 24 01:32:43 EDT 2016 by csabuild in /rel0.0/I270/panos/main

# Generated FRI SEPT 24 14:48:31 2016 UTC

exit all
configure
#------------------------------------------
echo "System Configuration"
#------------------------------------------
    system
        name "ALU-1"
        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://*:*@xxx.xxx.xxx.xx/home/csahwreg17/images/env.cfg”
        no boot-bad-exec
        no switchover-exec
        snmp
            engineID "0000197f00006883ff000000"
            packet-size 1500
            general-port 161
            no shutdown
        exit
        login-control
            ftp
                inbound-max-sessions 3
            exit
            ssh
                no disable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                ttl-security 100
            exit
            telnet
                no enable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                ttl-security 50
            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"
            login-banner
            no exponential-backoff
        exit
        atm
            no atm-location-id
        exit
        security
            management-access-filter
                default-action permit
                entry 1
                    no description
...
ALU-1>admin#

The tech-support command creates a system core dump.

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

CLI syntax:

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

Example:

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

The following example displays the save command results.

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

The reboot command reboots the router, including redundant CSMs 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 boot ROM and a reboot.

CLI syntax:

admin
    reboot [active | standby] | [upgrade] [now]

Example:

admin# reboot now

If synchronization fails, the standby does not reboot automatically. The show redundancy synchronization command displays synchronization output information.

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 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 (re)boots and are included in the configuration saves (admin>save).

CLI syntax:

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

Example:

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

The following example displays the command output:

ALU-1>config>system# info
#------------------------------------------
echo "System Configuration"
#------------------------------------------
        name "ALU-1"
        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/./ok.cfg"
        boot-bad-exec "ftp://test:test@192.168.xx.xxx/./fail.cfg"
        sync-if-timing
            begin
            ref-order ref1 ref2 bits
..
----------------------------------------------
ALU-1>config>system#

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

Use the following CLI syntax to enter the edit mode:

CLI syntax:

config>system>sync-if-timing
    begin

The following error message displays when you try to modify sync-if-timing parameters without entering begin first.

ALU-1>config>system>sync-if-timing>ref1# source-port 1/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 1/1/1.
ALU-1>config>system>sync-if-timing>ref1#

The following example shows the command usage:

Example:

config>system# sync-if-timing
config>system>sync-if-timing# begin
config>system>sync-if-timing# ref1
config>system>sync-if-timing>ref1# source-port1/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-port1/1/2
config>system>sync-if-timing>ref2# no shutdown
config>system>sync-if-timing>ref2# exit
config>system>sync-if-timing>commit

The following displays the timing reference parameters:

ALU-1>config>system>sync-if-timing# info
----------------------------------------------
            ref-order ref2 ref1
            ref1
                source-port 1/1/1
                no shutdown
            exit
            ref2
                no shutdown
                source-port 1/1/2
            exit

Use the following CLI syntax to configure basic IEEE 1588v2 PTP parameters.

CLI syntax:

config>system>ptp 
    clock clock-id [create]
        clock-mda mda-id
        clock-type {ordinary [master | slave] | boundary | transparent-e2e}
        domain domain-value
        dynamic-peers
        priority1 priority-value
        priority2 priority-value
        profile ieee1588-20008
        ptp-port port-id
            anno-rx-timeout number-of-timeouts
            log-anno-interval log-anno-interval
            log-sync-interval log-sync-interval
            peer peer-id ip-address {ip-address | ipv6-address}
            [no] shutdown
            unicast-negotiate
        [no] shutdown
        source-interface ip-if-name

config>system>sync-if-timing 
    ref1
        source-ptp-clock clock-id
    ref2
        source-ptp-clock clock-id

The following example shows the command usage:

Example:

config>system# ptp clock 1 create
config>system>ptp>clock# clock-type ordinary slave
config>system>ptp>clock# source-interface ptp-loop
config>system>ptp>clock# clock-mda 1/2
config>system>ptp>clock# domain 0
config>system>ptp>clock# no dynamic-peers
config>system>ptp>clock# priority1 128
config>system>ptp>clock# priority2 128
config>system>ptp>clock# profile ieee1588-2008
config>system>ptp>clock# ptp-port 1
config>system>ptp>clock>ptp-port# anno-rx-timeout 3
config>system>ptp>clock>ptp-port# log-anno-interval 1
config>system>ptp>clock>ptp-port# log-sync-interval -6
config>system>ptp>clock>ptp-port# unicast-negotiate
config>system>ptp>clock>ptp-port# peer 1
config>system>ptp>clock>ptp-port>peer# description "Peer to Boundary Clock"
config>system>ptp>clock>ptp-port>peer# ip-address 10.222.222.10
config>system>ptp>clock>ptp-port>peer# exit
config>system>ptp>clock>ptp-port# peer 2
config>system>ptp>clock>ptp-port>peer# description ToGM
config>system>ptp>clock>ptp-port>peer# ip-address 192.168.2.10
config>system>ptp>clock>ptp-port>peer# exit
config>system>ptp>clock>ptp-port# no shutdown
config>system>ptp>clock>ptp-port# exit
config>system>ptp>clock# no shutdown
config>system>ptp>clock# exit
config>system>ptp# exit
config>system# sync-if-timing begin
config>system>sync-if-timing# ref1
config>system>sync-if-timing>ref1# source-ptp-clock 1
config>system>sync-if-timing>ref1# no shutdown
config>system>sync-if-timing>ref1# exit

The following display shows a basic IEEE 1588v2 PTP configuration:

ALU-1>config>system>ptp># info   
#--------------------------------------------------
echo "System IEEE 1588 PTP Configuration"
#--------------------------------------------------
    system
        ptp
            clock 1 create
                clock-type ordinary slave
                source-interface "ptp loop"
                clock-mda 1/2
                domain 0
                no dynamic-peers
                priority1 128
                priority2 128
                profile ieee1588-2008
                ptp-port 1
                    anno-rx-timeout 3
                    log-anno-interval 1
                    log-sync-interval -6
                    unicast-negotiate
                    peer 1
                        description "Peer to Boundary Clock"
                        ip-address 10.222.222.10
                    exit
                    peer 2
                        description "ToGM"
                        ip-address 192.168.2.10
                    exit
                    no shutdown
                exit
                no shutdown
            exit
        exit
    exit

Use the following syntax to configure the quality level (QL) values for Synchronization Status Messaging (SSM). (The bits commands are only configurable on the 7705 SAR-18 and only if the router has version 1 of the Alarm module):

CLI syntax:

config>system>sync-if-timing 
    abort
    begin
    external
        input-interface 
            impedance {high-impedance | 50-ohm | 75-ohm}
            no shutdown
            ql-override {prs | stu | st2 | tnc | st3e | st3 | smc | prc | ssu-a | ssu-b | sec | eec1 | eec2}
            type {2048khz-G703 | 5mhz | 10mhz}
    commit
    bits
        input
            [no] shutdown 
        interface-type {ds1[{esf|sf}] | e1[{pcm30crc | pcm31crc}] | 2048khz-G703}
        output
            line-length {110|220|330|440|550|660}
            [no] shutdown
        ql-override {prs | stu | st2 | tnc | st3e | st3 | smc | prc | ssu-a | ssu-b | sec | eec1 | eec2}
        ssm-bit sa-bit
            [no] shutdown
        ql-selection
        ref-order first second [third]
        ref1
            ql-override {prs | stu | st2 | tnc | st3e | st3 | smc | prc | ssu-a | ssu-b | sec | eec1 | eec2}
            source-port port-id adaptive
            no shutdown
        ref2
            ql-override {prs | stu | st2 | tnc | st3e | st3 | smc | prc | ssu-a | ssu-b | sec | eec1 | eec2}
            source-port port-id adaptive
            no shutdown

The following example shows the command usage:

Example:

config>system# sync-if-timing
config>system>sync-if-timing# begin
config>system>sync-if-timing# external
config>system>sync-if-timing>external# input-interface
config>system>sync-if-timing>external>input-interface# impedance 50-Ohm
config>system>sync-if-timing>external>input-interface# no shutdown
config>system>sync-if-timing>external>input-interface# ql-override prs
config>system>sync-if-timing>external>input-interface# exit
config>system>sync-if-timing>external# exit
config>system>sync-if-timing# commit
config>system>sync-if-timing# bits
config>system>sync-if-timing>bits# interface-type 2048khz-G703
config>system>sync-if-timing>bits# ssm-bit 8
config>system>sync-if-timing>bits# output
config>system>sync-if-timing>bits>output# line-length 220
config>system>sync-if-timing>bits>output# no shutdown
config>system>sync-if-timing>bits>output# exit
config>system>sync-if-timing>bits# ql-override prs
config>system>sync-if-timing>bits# exit
config>system>sync-if-timing# ql-selection
config>system>sync-if-timing# ref1
config>system>sync-if-timing>ref1# shutdown
config>system>sync-if-timing>ref1# ql-override prs
config>system>sync-if-timing>ref1# exit
config>system>sync-if-timing# ref2
config>system>sync-if-timing>ref2# no shutdown
config>system>sync-if-timing>ref2# ql-override prs
config>system>sync-if-timing>ref2# exit
config>system>sync-if-timing# exit

The following display shows a basic SSM QL configuration for the 7705 SAR-8 Shelf V2:

ALU-1>config>system>sync-if-timing# info 
----------------------------------------------
ref-order external ref1 ref2
            ql-selection
            external
               input-interface 
                   no shutdown
                   impedance 50-Ohm
                   type 2048Khz-G703
                   ql-override prs
               exit
               output-interface
                   type 2048Khz-G703
               exit
            exit
            ref1
                no shutdown
                no source-port
                ql-override prs
            exit
            ref2
                no shutdown
                no source-port
                ql-override prs
            exit
            no revert
----------------------------------------------
*ALU-1>>config>system>sync-if-timing#

The following display shows a basic SSM QL configuration for the 7705 SAR-18 (with Alarm module version 1):

ALU-1>config>system>sync-if-timing# info 
----------------------------------------------
ref-order external ref1 ref2
            ql-selection
            exit
            bits
               interface-type 2048Khz-G703
               ssm-bit 8
               ql-override prs
               output
                   line-length 220
                   no shutdown
               exit
            ref1
                no shutdown
                no source-port
                ql-override prs
            exit
            ref2
                no shutdown
                no source-port
                ql-override prs
            exit
            no revert
----------------------------------------------

The revert command allows the clock to revert to a higher-priority reference if the current reference goes offline or becomes unstable. With revertive switching enabled, the highest-priority valid timing reference is used. If a reference with a higher priority becomes valid, a reference switchover to that reference initiates. If a failure on the current reference occurs, the next highest reference takes over.

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

CLI syntax:

config>system>sync-if-timing 
    revert

Other editing commands include:

• 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

CLI syntax:

config>system>sync-if-timing 
    abort
    commit

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

When the command is executed, the current system synchronous timing output is immediately referenced from the specified reference input. If the specified input is not available (shut down), or in a disqualified state, the timing output enters a holdover state based on the previous input reference.

Debug configurations are not saved between reboots.

CLI syntax:

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

Example:

debug>sync-if-timing# force-reference