System management

You can configure a name for the system 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 command to configure the system name.

configure system name

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

configure system contact

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

configure system location

You can optionally configure 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 command to configure the system coordinates.

configure system coordinates

Do not configure named objects with a name that starts with ‟_tmnx_”, or with ‟_” in general.

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

DNS Security (DNSSEC) Extensions are now implemented in the SR OS, allowing operators to configure DNS behavior of the router to evaluate whether the Authenticated Data bit was set in the response received from the recursive name server and to trust the response, or ignore it.

Setting a time zone in SR OS allows for times to be displayed in the local time rather instead of UTC. SR OS 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 in length and is unique 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.

configure system time prefer-local-time

• log filenames and log header information

• times in rollback information

• times in rollback and configuration files header information

• times related to CRON scripts

• times in the event handler system

• times in NETCONF and gRPC date-and-time leafs

configure log log-id time-format

The SR OS system-defined time zones are listed in System-defined time zones, 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 more importantly they can maintain time in a more synchronized fashion between all participating network nodes.

SR OS uses an NTP process based on a reference build provided by the Network Time Foundation. Nokia strongly recommends that the users review RFC 8633, Network Time Protocol Best Current Practices, when they plan to use NTP with the router. The RFC section ‟Using Enough Time Sources” indicates that using only two time sources (NTP servers) can introduce instability if they provide conflicting information. To maintain accurate time, Nokia recommends configuring three or more NTP servers.

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

SR OS routers normally operate as a stratum-2 or higher device. The router relies on an external stratum-1 server to source accurate time into the network. However, SR OS also allows for the use of the local PTP recovered time to be sourced into NTP. In this latter case, the local PTP source appears as a stratum-0 server and SR OS advertises itself as a stratum-1 server. Activation of the PTP source into NTP may impact the network NTP topology because the SR OS router is promoted to stratum-1.

SR OS router runs a single NTP clock which then 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.

NTP operates associations between clocks as either client or server, symmetric active and symmetric passive, or broadcast modes. These modes of operation are applied according to which elements are configured on the router. To run server mode, the operator must enable NTP server mode for the base and each needed VPRN routing instance. To run client mode, the operator must configure external servers. If both the local router and remote router are configured with each other as peers, then the router operates in symmetric active mode. If only one side of the association has peering configured, then the modes are symmetric passive. To operate using broadcast mode, interfaces must be configured to transmit as broadcast servers or receive as broadcast clients.

NTP server operation for both unicast and broadcast communication within a VPRN is configured within the VPRN (see the NTP Within a VPRN Service section in 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN).

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. The node, by default, transmits NTP packets in NTP version 4 mode.

• authentication keys

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

• operation in symmetric active mode

  This capability requires that NTP be 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.

• server and peer addressing using IPv6

  Both external servers and external peers may be defined using IPv6 or IPv4 addresses. Other features (such as multicast, broadcast) use IPv4 addressing only.

• broadcast or multicast modes

  When operating in these modes, the node receives or sends using either a multicast (default 224.0.1.1) or a broadcast address. Multicast is supported only on the CPM MGMT port.

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

• gradual clock adjustment

  As several applications (such as Service Assurance Agent (SAA)) can use the clock, and if determined that a major (128 ms or more) adjustment needs to be performed, the adjustment is performed by programmatically stepping the clock. If a minor (less than 128 ms) adjustment must be performed, then the adjustment is performed by either speeding up or slowing down the clock.

• To avoid the generation of too many events/trap the NTP module rates limit the generation of events/traps to three per second. At that point a single trap is generated that indicates that event/trap squashing is taking place.

Synchronization between the CPMs includes the following:

• Configuration and boot-env synchronization

• State database synchronization

The CRON feature supports periodic and date and time-based scheduling in SR OS. CRON can be used, for example, to schedule Service Assurance Agent (SAA) functions. CRON functionality includes the ability to specify scripts that need to be run, when they are scheduled, including one-time only functionality (one-shot), interval and calendar functions. 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 supports the schedule element. The schedule function configures the type of schedule to run, including one-time only (one-shot), periodic, or calendar-based runs. All runs are determined by month, day of month or weekday, hour, minute, and interval (seconds).

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

See the 7450 ESS, 7750 SR, and VSR Multiservice ISA and ESA Guide for information about redundancy for the Integrated Service Adapter (ISA).

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 IOMs, XCMs and XMAs.

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, and also requires that surrounding routers adhere to separate extension standards for each protocol. Every router vendor must support protocol extensions for interoperability.

With nonstop routing (NSR) on the SR-series router devices, 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 SR-series routers supports all routing protocols. NSR makes it possible to keep the existing sessions (BGP, LDP, OSPF, and so on) during a CPM switchover, including support for MPLS signaling protocols. Peers do not see any change.

Protocol extensions are not required. There are no interoperability issues and there is no need to define protocol extensions for every protocol. Unlike nonstop forwarding and graceful restart, the forwarding information in NSR is always up to date, which eliminates possible blackholes or forwarding loops.

Traditionally, addressing high availability issues have been patched through non-stop forwarding solutions. With the implementation of NSR, these limitations are overcome by delivering an intelligent hitless failover solution. This enables a carrier-class foundation for transparent networks, required to support business IP services backed by stringent SLAs. This level of high availability poses a major issue for conventional routers whose architectural design limits or prevents them from implementing NSR.

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 can occur if a switchover is forced from an active CPM to a standby, using the admin redundancy force-switchover command. Use the following command to configure a batch file that executes automatically after a CPM failover:

• MD-CLI

  configure redundancy switchover-exec

• classic CLI

  configure system switchover-exec

Synchronization between the CPMs includes the following:

• Configuration and boot-env synchronization

• State database synchronization

A high rate of DHCP renewals can create a load on the compact flash file system when subscriber management and DHCP server persistence is enabled. To optimize the access to the Dynamic Data Persistency (DDP) files on the compact flash, a lease-time threshold can be specified that controls the eligibility of a DHCP lease for persistency updates when no other data other than the lease expiry time is to be updated.

The following example shows the configuration of a DHCP lease-time threshold.

[ex:/configure system persistence]
A:admin@node-2# info
    dhcp-server {
        location cf2
    }
    subscriber-mgmt {
        location cf2
    }
    options {
        dhcp-leasetime-threshold 90061
    }

A:node-2>config>system>persistence# info
----------------------------------------------
            subscriber-mgmt
                location cf2:
            exit
            dhcp-server
                location cf2:
            exit
            options
                dhcp-leasetime-threshold days 1 hrs 1 min 1 sec 1
            exit
----------------------------------------------

DS1 signals can carry an indication of the quality level of the source generating the timing information using the SSM transported within the 1544 kb/s Extended Super Frame (ESF) Data Link (DL) of the signal as specified in Recommendation G.704. No such provision is extended to SF formatted DS1 signals.

The format of the data link messages in ESF frame format is "0xxx xxx0 1111 1111", transmitted rightmost bit first. The six bits denoted "xxx xxx" contain the actual message; some of these messages are reserved for synchronization messaging. It takes 32 frames (such as 4 ms) to transmit all 16 bits of a complete DL.

E1 signals can carry an indication of the quality level of the source generating the timing information using the SSM as specified in Recommendation G.704.

One of the Sa4 to Sa8 bits, (the actual Sa bit is for operator selection), is allocated for Synchronization Status Messages. To prevent ambiguities in pattern recognition, it is necessary to align the first bit (San1) with frame 1 of a G.704 E1 multi-frame.

The numbering of the San (n = 4, 5, 6, 7, 8) bits. A San bit is organized as a 4-bit nibble San1 to San4. San1 is the most significant bit; 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.

The SSM of SDH and SONET interfaces is carried in the S1 byte of the frame overhead. Each frame contains the four bit value of the QL.

DS3/E3 signals are not required to be synchronous. However, it is acceptable for their clocking to be generated from a synchronization source. The 7750 SR and the 7450 ESS allow E3/DS3 physical ports to be specified as a central clock input reference.

DS3/E3 signals do not support an SSM channel. QL-override should be used for these ports if ql-selection is enabled

The IEEE 1588v2 standard allows for synchronization of 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 unicast UDP/IPv4 or multicast Ethernet.

As part of the basic synchronization timing computation, a number of event messages are defined for synchronization messaging between the PTP timeReceiver port and PTP timeTransmitter port. 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. Ordinary clock timeTransmitter and boundary clock timeTransmitter ports use one-step operation; ordinary clock timeReceiver and boundary clock timeReceiver ports can accept messages from either one-step or two-step operation timeTransmitter ports.

The IEEE 1588v2 standard includes a mechanism to control the topology for synchronization distribution. The Best TimeTransmitter Clock Algorithm (BTCA) defines the states for the PTP ports on a clock. One port is set into timeReceiver state and the other ports are set to timeTransmitter (or passive) states. Ports in timeReceiver state recovered synchronization delivered by from an external PTP clock and ports in timeTransmitter state transmit synchronization to toward external PTP clocks.

The basic synchronization timing computation between the PTP timeReceiver and PTP timeTransmitter is shown in PTP timeReceiver and timeTransmitter time synchronization computation. This figure illustrates the offset of the timeReceiver clock referenced to the best timeTransmitter signal during startup.

When using IEEE 1588v2 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 contain information of the relative frequencies of the timeTransmitter clock and timeReceiver clock but has a noise component related to the packet delay variation (PDV) experienced across the network. The timeReceiver must filter the PDV effects so as to extract the relative frequency data and then adjust the timeReceiver frequency to align with the timeTransmitter frequency.

When using IEEE 1588v2 for distribution of time, the 7750 SR and 7450 ESS use the four timestamps exchanged using the IEEE 1588v2 messages to determine the offset between the router time base and the external timeTransmitter clock time base. The router determines the offset adjustment and then in between these adjustments, the router maintains the progression of time using the frequency from the central clock of the router. This allows time to be maintained using a BITS input source or 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 a system timing input reference enabled. Using IEEE 1588v2 for time distribution displays how IEEE 1588v2 is used for time distribution.

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, then 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 detecting and time stamping the IEEE 1588v2 packets at the Ethernet interface. This capability is referred to as port-based time stamping.

For each PTP message type to be exchanged between the router and an external 1588 clock, a unicast session must be established using the unicast negotiation procedures. The router allows the configuration of the message rate to be requested from external 1588 clocks. The router also supports a range of message rates that it grants to requests received from the external 1588 clocks. The IEEE 1588 standard allows the grantor port to respond with a shorter duration than what was in the request. The router can accept such a grant and uses that duration. The router issues a renegotiation before the duration expires.

Message rates ranges and defaults describes the ranges for both the rates that the router can request and grant.

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

Traditionally, only clock frequency is required to ensure smooth transmission in a synchronous network. The PTP ordinary clock with timeReceiver capability on the router 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. timeReceiver clock shows a PTP ordinary timeReceiver clock network configuration.

The PTP timeReceiver capability is implemented on the CPM, version 3 or later. The IEEE 1588v2 messages can ingress and egress the router on any line interface. Ordinary timeReceiver clock operation shows the operation of an ordinary PTP clock in timeReceiver mode.

The router supports the PTP ordinary clock in timeTransmitter mode. Normally, an IEEE 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 closer to the edge of the network, as close to the timeReceiver clocks as possible. PTP timeTransmitter clock shows a PTP timeTransmitter clock network configuration.

All packets are routed to their destination via the best route as determined in the route table; see Ordinary timeTransmitter clock operation. It does not matter which ports are used to ingress and egress these packets (unless port based time stamping is enabled for higher performance).

The router 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, utilization 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 various 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, as shown in Boundary clock.

In addition, the use of port-based timestamping in every network element between the grandmaster and the end timeReceiver application is highly recommended for delivering time to meet one microsecond accuracies required of mobile applications.

The router always uses the frequency output of the central clock to maintain the timebase within the router. The PTP reference into the central clock should always be enabled as an option if the router is configured as a boundary clock. This avoids the situation of the router entering holdover while propagating time with 1588.

The PTP module in the router exists on the CPM. The PTP module on the standby CPM is kept synchronized to the PTP module on the active CPM. All sessions with external PTP peers are maintained over a CPM switchover.

For physical ports located on an MDA/IMM/XMA/MDA-s of a 7750 SR or a 7950 XRS platform, PTP messages are supported in the following encapsulations:

• PTP within raw Ethernet (no VLAN header)
• PTP within UDP/IPv4 within raw Ethernet (no VLAN header)
• PTP within UDP/IPv4 within dot1q Ethernet (one VLAN header)

For the SyncE/1588 ports located on the CPM or CCM of a 7750 SR or a 7950 XRS platform, PTP supports PTP messages within raw Ethernet (no VLAN header).

For physical ports located on a 7210 SAS satellite, PTP supports PTP messages within raw Ethernet (no VLAN header).

No other encapsulations are supported.

PTP has the potential to provide much more accurate time into the router than can be obtained with NTP. This PTP recovered time can be made available for system time and OAM packet time stamping to improve the accuracies of logged events and OAM delay measurements. The mechanism to activate PTP as the source for these internal time bases is to allocate PTP as a local server into NTP. This allows the NTP time recovery to use PTP as a source for time and then distribute it within the router to system time and the OAM process. This activation also affects the operation of the NTP server within the SR OS. The PTP server appears as NTP stratum 0 server and therefore the SR OS advertises itself as an NTP Stratum 1 server to external peers and clients. This activation may impact the NTP topology.

PTP is supported over direct Ethernet encapsulation (that is, PTP ports) and UDP/IP encapsulation (that is, PTP peers). PTP ports operate below the routing plane. They can be used on appropriate ports irrespective of any type of router interface also on the port. PTP peers operate at the routing plane and have restrictions based on and across the following router instances.

Transmission and reception of PTP messages using PTP peers is supported in the following contexts:

• Network interface in the Base routing instance (configure router interface)

• IES interface (configure service ies interface)

• VPRN interface (configure service vprn interface)

Transmission and reception of PTP messages using PTP peers is not supported in the following contexts:

• IES spoke SDP interface (configure service ies spoke-sdp interface)

• VPRN spoke SDP interface (configure service vprn spoke-sdp interface)

• VPRN transport tunnel (configure service vprn auto-bind-tunnel or configure service vprn spoke-sdp)

• Any interface of the management router instance

• Any interface of the vpls-management router instance

• Any interface of a user created CPM router instance

It is important to note that there is only one PTP clock within the router. All PTP ports and PTP peers communicate into one clock instance. Only one router instance may have PTP peers configured, which means that only that router instance (or PTP port) can run the timeReceiver functionality and recover time from an external PTP clock. All other router instances only support the dynamic PTP peers. The PTP process in the router only includes outward server time toward the dynamic PTP peers. The dynamic PTP peers are shared across all router instances. If it is needed to control the number of dynamic peers that can be consumed by a routing instance, then it must be configured for that routing instance.

The PTP clock in the router monitors the Sync, Follow_Up (if present), and Delay_Resp messages received from external neighbor ports. If a high variation is detected in the network path between the external neighbor port and the local port, that neighbor port is considered unusable (PTSF-unusable as defined in the ITU-T G.8275.1 recommendation). When a neighbor is unusable, all Announce messages from that neighbor are discarded on reception and excluded from the BMCA. If the neighbor is the parent clock to the local clock, the local clock must either select a new parent clock or go into holdover. In addition, any neighbor clock marked as unusable cannot act as the parent to the local PTP clock until underlying condition is investigated and resolved, and the unusable state is cleared. The unusable state is cleared when PTP, PTSF-unusable monitoring, or the local PTP port is administratively disabled, the PTP port is deleted, or the external neighbor port stops sending messages to the node. It can also be cleared by using the appropriate clear command.

There is one PTP clock within an SR OS system. The clock runs a BTCA and can set a port into timeReceiver state to recover frequency, time, or both. The recovery process is controlled by the rules of a primary profile. The SR OS also allows frequency, time, or both to be distributed outward from the clock using PTP messages that conform to the rules of an alternate profile. The primary profile and alternate profiles include a parameter to configure the standard profile that defines these rules. The following guidelines apply to profile interworking:

• Alternate profiles can only be configured if the primary profile is using standard profile g8275dot1-2014 or g8275dot2-2016.
• Alternate profiles can use standard profiles ieee1588-2008, g8265dot1-2010, g8275dot1-2014, or g8275dot2-2016.
• The primary profile and an alternate profile can use the same standard profile.
• Multiple alternate profiles can also use the same standard profile.

Alternate profiles are associated with PTP ports and peers. Alternate profile associations are configured for PTP ports and learned by PTP peers. PTP peer alternate profiles are learned by matching the domain number of received unicast messaging with the domain of the configured alternate profile.

The following table lists the profile interworking between the primary and alternate profiles depending on the standard profile used in the primary.

When referencing satellite ports, always use 1 for the slot number.

Use the following format to reference Ethernet satellite client ports:

port esat-sat-id/1/portNum

port esat-4/1/2

port esat-sat-id/1/uportNum

port esat-5/1/u2

port tsat-sat-id/1/portNum.channel

port tsat-3/1/4.1

port tsat-sat-id/1/uport.channel

port tsat-4/1/u1.1

The local forwarding capability allows traffic to be forwarded between two client satellite ports without going through the SR host, which allows for optimal forwarding by preserving uplink bandwidth.

• Locally forwarded traffic is identified based on the ingress VLAN tag.

• The outer VLAN tag used to identify the traffic to be locally forwarded can be different at the two bypass endpoints. In that case, as traffic is forwarded from the ingress to the egress, the outer VLAN tag is modified.

• The bypass paths are bidirectional, so only a single local-forwarding path needs to be defined to allow for traffic flow in both directions.

Local forwarding shows an example of local forwarding.

A local-forward bypass is created by using the following commands to create a local-forward bypass, then associating a set of two satellite access points as endpoints for the local-forward bypass.

• The two endpoints must be ports on the same Ethernet satellite chassis.

• If a LAG is used as an endpoint, all member links must be ports on the same Ethernet satellite.

• All satellite ports must be client ports by default, or must be configured as a client port using the port-template command.

The following example shows the commands to configure a local-forward bypass between client ports esat-2/1/1:66 and esat-2/1/50:101.

[ex:/configure satellite]
A:admin@node-2# info
    ethernet-satellite 10 {
        admin-state enable
        description "local-forward to offload router"
        port-map esat-2/1/1 {
        }
        port-map esat-2/1/50 {
        }
    }

A:node-2>config>system>satellite# info
----------------------------------------------
          local-forward 10 create
               description "local-forward to offload router"
               sap esat-2/1/1:66 create
               exit
               sap esat-2/1/50:101 create
               exit
               no shutdown
          exit
----------------------------------------------

The port-template command hierarchy allows the creation of a satellite template that reconfigures the port role and uplink association for one or more satellite ports. This template can then be applied to one or more Ethernet satellite instances, in which case those satellites inherit the specified port role and uplink associations.

The port template is necessary when reconfiguring a satellite uplink as a client port for use as part of a local-forward bypass path. Use the following command to create satellite templates:

• MD-CLI

  configure satellite port-template

• classic CLI

  configure system satellite port-template

Ports 51 and 52 on the 48xGE + 4x10GE satellite chassis can be reassigned as client ports instead of uplink ports. This provides the flexibility to offer 10GE services from these satellite chassis. These two 10GE ports can be reconfigured as client ports using the port-template configuration commands described above. The port template configuration must be done before SAPs, interfaces, or services can be applied to the associated satellite ports.

Ports 67 and 68 on the 64x10GE + 4x100GE satellites (sat-type es64-10gb-sfpp+4-100gb-cfp4) and connectors 3 and 4 on the 64x10GE+4xQSFP28 (sat-type es64-10gb-sfpp+4-100gb-qsfp28) can be reassigned as client ports instead of uplinks. This provides the flexibility to offer 100GE services from these satellite chassis. These two 100GE ports can be reconfigured as client ports using the port-template configuration commands. The port template must be configured before port topology bindings are configured as well as before SAPs, interfaces, or services can be applied to the associated satellite ports.

On the 7210 SAS-Sx 64x10GE+4x100GE (es64-10gb-sfpp+4-100gb-cfp4) and 64x10GE+4xQSFP28 (sat-type es64-10gb-sfpp+4-100gb-qsfp28) satellite, selected 10GE ports can be reconfigured and used as satellite uplinks to the host router running SR OS.

Up to 16 10GE interfaces can be used as uplinks for the associated satellite. You must create a new satellite template that configures the needed 10GE interfaces as uplinks. In addition, use a port template to specify the uplink association between the remaining client ports and configured uplinks.

Apply the new template to the satellite using the template-name command, where the template-name is the name configured in the port-template context.

This feature requires the 7210 SAS-Sx to be running Release 9.0.R10 or later for the SAS-Sx 64x10GE+4x100GE and 7210 SAS Release 10.0 or later for the 64x10GE+4xqSFP28 satellite.

The following restrictions apply:

• The 10GE ports used as satellite uplinks must start at port 1 and be sequential, up to the maximum of 16 10GE uplinks.

• When 10GE ports are used as uplinks, the 4x100GE port are not available for use and should be configured as role none.

The following example shows the configuration.

[ex:/configure satellite]
A:admin@node-2# info
    port-template "10gUp" {
        admin-state enable
        sat-type es64-10gb-sfpp+4-100gb-cfp4
        port "1/1/1" {
            role uplink
        }
        port "1/1/2" {
            role uplink
        }
        port "1/1/3" {
            role uplink
        }
        ...
        port "1/1/9" {
            uplink 1/1/1
        }
        port "1/1/10" {
            uplink 1/1/1
        }
        ...
        port "1/1/16" {
            uplink 1/1/2
        }
        port "1/1/17" {
            uplink 1/1/2
        }
        port "1/1/65" {
            role none
        }
        port "1/1/66" {
            role none
        }
        ...
    }
    ethernet-satellite 20 {
        admin-state enable
        mac-address d0:99:d5:96:ee:41
        sat-type es64-10gb-sfpp+4-100gb-cfp4
        software-repository rep1
        port-template "10gUp"
    }

A:node-2>config>system>satellite# info
----------------------------------------------
          port-template "10gUp" sat-type "es64-10gb-sfpp+4-100gb-cfp4" create
               port 1/1/1
                    role uplink
                    uplink none
               exit
               port 1/1/2
                    role uplink
                    uplink none
               exit
               port 1/1/3
                    role uplink
                    uplink none
               exit
               ...
               port 1/1/9
                    uplink 1/1/1
               exit
               port 1/1/10
                    uplink 1/1/1
               exit
               ...
               port 1/1/16
                    uplink 1/1/2
               exit
               port 1/1/17
                    uplink 1/1/2
               exit
               ...
               port 1/1/65
                    role none
               exit
               port 1/1/66
                    role none
               exit
               ...
               no shutdown
          exit
          eth-sat 20 create
               mac-address d0:99:d5:96:ee:41
               sat-type "es64-10gb-sfpp+4-100gb-cfp4"
               port-template "10gUp"
               software-repository "rep1"
               no shutdown
          exit
----------------------------------------------

An option in the port-map configuration allows a secondary uplink to be assigned to enable uplink resiliency. A secondary uplink is used to carry the traffic associated with the client port if the primary uplink becomes unavailable. If traffic is switched to the secondary uplink, when the primary uplink becomes available, traffic is reverted to the primary as soon as possible.

Use the following command to configure a secondary uplink per client port:

• MD-CLI

  configure satellite ethernet-satellite port-map secondary

• classic CLI

  configure system satellite eth-sat port-map secondary

To configure a secondary uplink, after the primary uplink is specified, the secondary keyword should be included, followed by the intended uplink to be used as the secondary uplink.

[ex:/configure satellite]
A:admin@node-2# info
     ethernet-satellite 1 {
          port-map esat-1/1/2 {
               primary esat-1/1/u1
               secondary esat-1/1/u3
          }
     }

A:node-2>config>system>satellite# info
----------------------------------------------
          eth-sat 1 create
               port-map esat-1/1/2
               primary esat-1/1/u1
               secondary esat-1/1/u3
          exit
----------------------------------------------

The host system can use the dynamic uplink resiliency mechanism to automatically manage uplink resiliency assignments. Through this mechanism, the host dynamically assigns a primary and secondary uplink for each satellite access port. Depending on the configuration options specified, the uplinks (primary and secondary) can be distributed over one or two FP forwarding engines.

[ex:/configure satellite]
A:admin@node-2# info
    ethernet-satellite 1 {
        admin-state enable
        sat-type es48-1gb-sfp
        dynamic-uplink true
        uplink-distribution dual-complex
    }

A:node-2>config>system>satellite# info
----------------------------------------------
          eth-sat 1 create
               sat-type es48-1gb-sfp
               dynamic-uplink true
               uplink-distribution dual-complex
               no shutdown
          exit
----------------------------------------------

Ethernet LAGs can use a mixture of physical Ethernet ports (including connector-based ports) and satellite access ports. However, satellite access ports are not supported within mixed speed LAGs.

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 CPM (in redundant systems). The synchronization options on the standby CPM are preserved.

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

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

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

Both image files (CPM and IOM) on the 7450 ESS must be located in the same directory. Failure to locate and synchronize both images causes an error to be generated.

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

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

This section covers the basic system information to configure the physical location of the router, contact information, location information (the place the router is located such as an address, floor, room number, and so on), global positioning system (GPS) coordinates, and system name.

When configuring the associated LAG ID, the LAG must be in access mode and LACP must be enabled. The following example configures multi-chassis redundancy features.

[ex:/configure redundancy multi-chassis]
A:admin@node-2# info
    peer 10.10.10.2 {
        admin-state enable
        description "Mc-Lag peer 10.10.10.2"
        mc-lag {
            admin-state enable
            lag "lag-1" {
                lacp-key 32666
                system-id 00:00:00:33:33:33
                system-priority 32888
            }
        }
    }

A:node-2>config>redundancy>multi-chassis# info
---------------------------------------------
        peer 10.10.10.2 create
            description "Mc-Lag peer 10.10.10.2"
            mc-lag
                no shutdown
            exit
            no shutdown
        exit
---------------------------------------------

The following example configures power supply settings for the 7750 SR, 7950 XRS, and 7450 ESS.

[ex:/configure chassis router chassis-number 1]
A:admin@node-2# info
    power-supply 1 {
        power-supply-type dc-single
    }

A:node-2>config>system# info
----------------------------------------------
        power-supply 1 dc
----------------------------------------------

You can specify the maximum number of backup versions of configuration and index files kept in the primary location.

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 SF/CPMSF/CPM is performed for all configurations and their associated persistent index files. Use the following command to configure the maximum number of backup versions:

• MD-CLI

  configure system management-interface configuration-save configuration-backups

• classic CLI

  configure system config-backup

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 bootup configuration. A URL must be specified or no action is taken. The commands are persistent between router boots or reboots and are included in the configuration saves. Use the following commands to configure post-boot extension files.

configure system boot-bad-exec
configure system boot-good-exec

This applies to classic CLI.

To enter the mode to edit timing references, you must enter the begin keyword.

Use the following command to enter the edit mode:

config>system>sync-if-timing# begin

The following error message shows when the you try to modify sync-if-timing parameters without entering the keyword begin.

A:node-2>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:node-2>config>system>sync-if-timing>ref1#

Use commands in the following context to configure timing reference settings:

• MD-CLI

  configure system central-frequency-clock

• classic CLI

  configure system sync-if-timing

The source port specified for ref1 and ref2 is dependent on the router model type and chassis slot. See the details in the specific command descriptions in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

The revert command allows the clock to revert to a higher priority reference if the current reference goes offline or becomes unstable. When the failed reference becomes operational, it is eligible for selection.

When mode is non-revertive, a failed clock source is not selected again. If a node enters holdover because of the references being in previous failed state, then the node selects one of the previously failed references instead of going into holdover. Use the following command to enable revert mode:

• MD-CLI

  configure system central-frequency-clock revert true

• classic CLI

  configure system sync-if-timing revert

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

When revertive switching enabled a valid timing reference of the highest priority is used. If a reference with a higher priority becomes valid, a reference switch over 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 valid active reference always remains selected even if a higher priority reference becomes available. If the active reference becomes invalid, a reference switch over to a valid reference with the highest priority is initiated. The failed reference is eligible for selection when it becomes operational. Use the following command to turn off revert mode:

• MD-CLI

  configure system central-frequency-clock revert false

• classic CLI

  configure system sync-if-timing no revert

Use the following command to save changes made to the timing references during a session. Modifications are not persistent across system boots unless you enter this command.

• MD-CLI

  configure system central-frequency-clock commit

• classic CLI

  configure system sync-if-timing commit

Use the following command to discard changes that have been made to the timing references during a session:

• MD-CLI

  configure system central-frequency-clock discard

• classic CLI

  configure system sync-if-timing abort

This applies to the classic CLI.

The debug sync-if-timing force-reference command should only be used to test and debug problems. Network synchronization problems may appear if network elements are left with this manual override setting. When the system timing reference input has been forced, it may be cleared using the no force-reference command.

Force the CPM clock to use a specific input reference using the force-reference command.

When the command is executed, the CPM clock on the active CPM immediately switches its input reference to that specified by the command. If the specified input is not available (shutdown), or in a disqualified state, the CPM clock shall use the next qualified input reference based on the selection rules.

This command also affects the BITS output port. If the BITS output port selection is set to line-reference and the reference being forced is not the BITS input port, then the system uses the forced reference to generate the signal out the BITS output port. If the BITS output port selection is set to internal-clock, then the system uses the output of the CPM clock to generate the signal for the BITS output port.

On a CPM activity switch, the force command is cleared and normal reference selection is determined.

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 be created to record the occurrence of the event. It can also specify whether an SNMP notification (trap) be generated for the event. There are two notifications for threshold crossing events, a rising alarm and a falling alarm.

Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the 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 whatever log destinations are configured: 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. 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. 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 and alarms and compact flash usage warnings and alarms.

The following example shows the command output.

[ex:/configure system thresholds]
A:admin@node-2# info
    cflash-cap-warn-percent "cf1-B:" {
        rising-threshold 100
        falling-threshold 50
        interval 240
        startup-alarm either
    }
    kb-memory-use-alarm {
        rising-threshold 50000000
        falling-threshold 45999999
        interval 500
        startup-alarm either
    }
    rmon {
        event 5 {
            description "alarm testing"
            owner "Timos CLI"
        }
    }

A:node-2>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
----------------------------------------------

Alarm contact inputs are physical input pins on the Alarms port that allow the operator to monitor and report changes in external environmental conditions. In a remote or outdoor deployment, alarm contact inputs typically allow an operator to detect specific conditions, such as, whether a door is open or closed, an air conditioner fault has occurred, and so on.

configure system alarm-contact-input normal-state

Nokia recommends the normal-state closed configuration so that an external power source failure triggers all the alarm pins to detect a change of state. If normal-state open is used with an external power source, an external power source failure does not generate any notifications.