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.
where direction is one of the four basic values: N, S, W, E,
hours ranges from 0 to 180 (for latitude) and 0 to 90 for longitude, and minutes and seconds range from 0 to 60.
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 certain functional categories of equipment unique to the telecommunications industry. The CLLI code is stored in the Alcatel-Lucent
Chassis MIB tmnxChassisCLLICode object.
7750 SR routers are equipped with a real-time system clock for time keeping purposes. When set, the system clock always operates on Coordinated Universal Time (UTC), but the SR OS software has options for local time translation as well as system clock synchronization.
The SR OS system-defined time zones are listed in Table 22 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.
|
•
|
Broadcast or multicast modes — When operating in these modes, the node will receive or send using either a multicast (default 224.0.1.1) or a broadcast address. Multicast is supported on the MGMT port.
|
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 or to schedule turning on and off policies to meet "Time of Day" (TOD) requirements. CRON functionality includes the ability to specify scripts that need to be run, when they will be 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.
Refer to the 7750 SR-Series OS Integrated Services Adapter Guide for information about redundancy for the Integrated Service Adapter (ISA).
Features configured on the active device CPM are saved on the standby CPM as well. When the active device CPM fails, these features are brought up on the standby device CPM that takes over the mastership.
7750 SR-Series component redundancy is critical to reduce MTTR for the system and primarily consists of the following router features:
|
•
|
Dual switch fabric — Failover to the backup switch fabric within a minimum time interval, preferably with no loss of traffic.
|
When there is a switchover and the standby CPM becomes active, the accounting servers will be checked and if they are administratively up and capable of coming online (media present, etc.), the standby will be brought online and new accounting files will be created at that point. Users must manually copy the accounting records from the failed CPM.
With NSR on the 7750 SR-Series routers 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 7750 SR-Series routers supports all routing protocols. NSR makes it possible to keep the existing sessions (BGP, LDP, OSPF, etc.) during a CPM switchover, including support for MPLS signaling protocols. Peers will not see any change.
|
•
|
To force a switchover from an active CPM to a standby, use the admin redundancy force-switchover command. You can configure a batch file that executes after failover by using the config system switchover-exec and admin redundancy force-switchover now CLI commands.
|
Synchronization between the CPMs includes the following:
Configuration and boot-env synchronization are supported in admin>redundancy> synchronize and config>redundancy>synchronize contexts.
If a new standby CPM is inserted into the system, it synchronizes with the active CPM upon a successful boot process.
If the standby CPM is rebooted, it synchronizes with the active CPM upon a successful boot process.
If the synchronization fails, the standby does not reboot automatically. The show redundancy synchronization command displays synchronization output information.
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 standby command on the active or the standby CPM.
7750 SR-Series routers supporting redundancy use a 1:1 redundancy scheme. Redundancy methods facilitate system synchronization between the active and standby Control Processor Modules (CPMs) so they maintain identical operational parameters to prevent inconsistencies in the event of a CPM failure.
When the boot-env parameter is specified, the BOF, boot.ldr, config, and image files are automatically synchronized. When the
config parameter is specified, only the config files are automatically synchronized.
When the boot-env parameter is specified, the BOF, boot.ldr, config, and image files are synchronized. When the
config parameter is specified, only the config files are synchronized.
A:ALA-12>admin>redundancy# synchronize config
Syncing configuration......
Syncing configuration.....Completed.
A:ALA-12#
Typically, the first Switch Fabric (SF)/CPM card installed in a redundant 7750 SR-Series chassis assumes the role as active, regardless of being inserted in Slot A or B. The next CPM installed in the same chassis then assumes the role as the standby CPM. If two CPM are inserted simultaneously (or almost simultaneously) and are booting at the same time, then preference is given to the CPM installed in Slot A.
If only one CPM is installed in a redundant router device, then
it becomes the active CPM regardless of the slot it is installed in.
To visually determine the active and standby designations, the Status LED on the faceplate is lit green (steady) to indicate the active designation. The Status LED on the second CPM faceplate is lit amber to indicate the standby designation.
The following output shows that the CPM installed in Slot A is acting as the active CPM and the CPM installed in Slot B is acting as the standby.
ALA-12# show card
===============================================================================
Card Summary
===============================================================================
slot card card card admin operational
allowed provisioned equipped state state
-------------------------------------------------------------------------------
2 all supported iom-20g iom-20g up up
A all supported sfm-400g sfm-400g up up/active
B all supported sfm-400g sfm-400g up up/standby
===============================================================================
ALA-12#
...
Slot A contains the Active CPM
When an active CPM goes offline (due to reboot, removal, or failure), the standby CPM takes control without rebooting or initializing itself. It is assumed that the CPMs are synchronized, therefore, there is no delay in operability. When the CPM that went offline boots and then comes back online, it becomes the standby CPM.
Active CPM in Slot A has stopped
Slot B is now active CPM
Attempting to exec configuration file:
'cf3:/config.cfg' ...
...
Executed 49,588 lines in 8.0 seconds from file cf3:\config.cfg
When a DHCP message is snooped, there are steps that make the data persistent in a system with dual CPMs. In systems with only one CPM, only Step 1 applies. In systems with dual CPMs, all steps apply.
|
1.
|
When a DHCP ACK is received from a DHCP server, the entry information is written to the active CPM Compact Flash. If writing was successful, the ACK is forwarded to the DHCP client. If persistency fails completely (bad cflash), a trap is generated indicating that persistency can no longer be guaranteed. If the complete persistency system fails the DHCP ACKs are still forwarded to the DHCP clients. Only during small persistency interruptions or in overload conditions of the Compact Flash, DHCP ACKs may get dropped and not forwarded to the DHCP clients.
|
The architecture shown in Figure 13 provides the following benefits:
The system can select from up to four timing inputs to train the local oscillator. The priority order of these references must be specified. This is a simple ordered list of inputs: {bits, ref1, ref2, ptp}. The CPM clock output shall have the ability to drive the clocking for all line cards in the system. The routers support selection of the node reference using Quality Level (QL) indications. See
Figure 14 for a description of synchronization reference selection.
The BITS ports accept T1 or E1 signal formats. Some hardware also supports the 2048 kHz signal format. The format must be common between all BITSin and BISout ports.
All settings of the signal characteristics for the BITS input applies to both ports. When the active CPM considers the BITS input as a possible reference, it will consider first the BITS input port on the active CPM followed the BITS input port on the standby CPM in that relative priority order. This relative priority order is in addition to the user definable ref-order. For example, a ref-order of ‘bits-ref1-ref2’ would actually be BITS in (active CPM) followed by BITS in (standby CPM) followed by ref1 followed by ref2. When ql-selection is enabled, then the QL of each BITS input port shall be viewed independently. The higher QL source shall be chosen.
The Table 23 shows the selection followed for two reference in both revertive and non-revertive modes:
Synchronous Ethernet allows operators to gracefully integrate existing systems and future deployments into conventional industry-standard synchronization hierarchy. The concept behind synchronous Ethernet is analogous to SONET/SDH system timing capabilities. It allows the operator to select any (optical) Ethernet port as a candidate timing reference. The recovered timing from this port will then be used to time the system (for example, the CPM will lock to this provisioned reference selection). The operator then could ensure that any of system output would be locked to a stable traceable frequency source.
Within the SR/ESS, there is also an internal quality level of QL-UNKNOWN. This is used to differentiate from a received QL-STU code but is equivalent for the purposes of QL selection.
Note: When the internal Quality level is in the range of 9 through 14, the output codes shown in Table 25, will only appear if QL selection is disabled. If ql-selection is enabled, then all of these internal states are changed to internal state 15 (Holdover) and the ssm value generated will reflect the holdover quality of the internal clock.
The 7750 SR supports the ordinary clock in slave or master mode or the boundary clock. When configured as an ordinary clock master, the 7750 SR can only provide frequency distribution using IEEE 1588v2. The boundary clock and ordinary clock slave can be used for both frequency and time distribution.
The 7750 SR communicates with neighboring IEEE 1588v2 clocks. These neighbor clocks can be ordinary clock masters, ordinary clock slaves, or boundary clocks. The communication can be based on either unicast IPv4 sessions transported through IP interfaces or multicast Ethernet transported through Ethernet ports.
For the unicast IP sessions, the external clocks are labeled 'peers'. There there are two types of peers: configured and discovered. The 7750 SR operating as an ordinary clock slave or as a boundary clock should have configured peers for each PTP neighbor clock from which it might accept synchronization information. The 7750 SR initiates unicast sessions with all configured peers. A 7750 SR operating as an ordinary clock master or boundary clock will accept unicast session requests from external peers. If the peer is not a configured peer, then it is considered a discovered peer. The 7750 SR can deliver synchronization information toward discovered peers.
Figure 15 shows the relationship of various neighbor clocks using unicast IP sessions to communicate with a 7750 SR configured as a boundary clock with two configured peers.
For multicast Ethernet operation, the node shall listen for and transmit PTP messages using the configured multicast MAC address. Neighbor clocks are discovered via the reception of messages through an enabled Ethernet port. The 7750 SR supports more than one neighbor PTP clock connecting into a single port. This might be encountered with the deployment of an Ethernet multicast LAN segment between the 7750 SR and the neighbor PTP ports using an End to end transparent clock or an Ethernet switch. The Ethernet switch is not recommended due to the introduction of PDV and the potential degradation of performance but it can be used if appropriate to the application.
Figure 16 shows the relationship of various neighbor clocks using multicast Ethernet sessions to a 7750 SR configured as a boundary clock. The 7750 SR has three ports configured for multicast Ethernet communications. Port 1/2/1 of the 7750 SR shows a connection where there are two neighbor clocks connecting to one port of the 7750 SR through an end-to-end transparent clock.
The 7750 SR allows for PTP operation over both unicast IPv4 and multicast Ethernet at the same time.
7750 SR currently supports three profiles:
When a 7750 SR receives
Announce messages from one or more configured peers or multicast neighbors, it executes a Best Master Clock Algorithm (BMCA) to determine the state of communication between itself and the peers. The system uses the BMCA to create a hierarchical topology allowing the flow of synchronization information from the best source (the Grandmaster clock) out through the network to all boundary and slave clocks. Each profile has a dedicated BMCA.
If the profile setting for the clock is
ieee1588-2008, the precedence order for the best master selection algorithm is as follows:
The 7750 SR sets its local parameters as follows:
If the profile setting for the clock is g8265dot1-2010, the precedence order for the best master selection algorithm is:
The 7750 SR sets its local parameters as follows:
If the profile setting for the clock is g8275dot1-2014, the precedence order for the best master selection algorithm is very similar to that used with the default profile. It ignores the
priority1 parameter, includes a
localPriority parameter and includes the ability to force a port to never enter slave state (
master-only). The precedence is as follows:
There is a limit on the number of external PTP clocks to which the 7750 BC/Slaves will request unicast service (# configured peers) and also a limit to the number of external PTP clocks to which the 7750 GM/BC will grant unicast service (# discovered peers). An association where the 7750 BC has a symmetric relationship with another 7750 BC (i.e. they both have the other as a configured peer) will consume a request and a grant unicast service in each 7750 BC.
Figure 17 shows the unicast negotiation procedure performed between a slave and a peer clock that is selected to be the master clock. The slave clock will request Announce messages from all peer clocks but only request Sync and Delay_Resp messages from the clock selected to be the master clock.
The basic synchronization timing computation between the PTP slave and PTP master is shown in Figure 18. This figure illustrates the offset of the slave clock referenced to the best master signal during startup.
When using IEEE 1588v2 for distribution of time, the 7750 SR uses the four timestamps exchanged using the IEEE 1588v2 messages to determine the offset between the 7750 SR time base and the external master clock time base. The 7750 SR determines the offset adjustment and then in between these adjustments, the 7750 SR maintains the progression of time using the frequency from the central clock of the node. 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.
In order for this to operate, the CPM, IOM, IMM, and MDAs must be running the firmware that supports the capability. The CPM firmware upgrade occurs automatically when the CPM card software is updated. Since upgrading of IOM, IMM, and MDA firmware is service impacting, this upgrade is not performed automatically on a soft reset of the MDA. The IOM/IMM firmware is upgraded when the IOM/IMM card is hard reset. The MDA firmware is programmed during system initialization, when the MDA is inserted, or when the MDA is hard reset via a
clear mda or
clear card command. However, when an MDA is soft reset via either a
clear card soft command or during a major ISSU, the MDA firmware is not updated.
For each PTP message type to be exchanged between the 7750 SR and an external 1588 clock, a Unicast Session must be established using the Unicast Negotiation procedures. The 7750 SR allows configuration of the message rate to be requested from external 1588 clocks. The 7750 SR also supports a range of message rates that it will grant to requests received from the external 1588 clocks.
Table 29 describes the ranges for both the rates that the 7750 SR can request and grant.
Traditionally, only clock frequency is required to ensure smooth transmission in a synchronous network. The PTP ordinary clock with slave capability on the 7750 SR 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.
Figure 20 shows a PTP ordinary slave clock network configuration.
The 7750 SR supports the PTP ordinary clock in master mode. Normally, a IEEE 1588v2 grand master is used to support many slaves and boundary clocks in the network. In cases where only a small number of slaves and boundary clocks exist and only frequency is required, a PTP integrated master 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 master clock closer to the edge of the network, as close to the slave clocks as possible.
Figure 22 shows a PTP master clock network configuration.
All packets are routed to their destination via the best route as determined in the route table; see Figure 23. It does not matter which ports are used to ingress and egress these packets (unless port based time stamping is enabled for higher performance).
In addition to based routing and IES services, PTP messaging is supported within VPRN services. PTP messaging is not supported through the management router instance. Only one PTP clock exists within the node and it is shared by all routing instances that have access. Only one routing instance may have configured peers and only this routing context can receive the time or frequency reference into the 7750 SR /7450 ESS (contain a PTP port in Slave state). The dynamic peers are shared across all routing instances; if it is desired to control the number of dynamic peers that can be consumed by a given routing instance then this must be configured for that routing instance.
The ATM OAM loopback parameters must be first enabled and configured in the config>system> atm>oam context and then enabled in the
IES or VPRN service interface SAP atm oam context.
Refer to the IES and VPRN sections of the 7750 OS Services Guide for further information.
The example displayed in Figure 26 depicts a MPLS network that uses Ethernet interfaces in the core or as an access/hand off interfaces to connect to different kind of Ethernet enabled devices such as service gateway/routers, QinQ switches, DSLAMs or customer equipment.
Note: The “ip-only” option and the IPv6 payload support with the “lbl-ip” option can only be enabled on IP interfaces on IOM3/IMM ports.
a: This mode corresponds to scaling and feature set associated with iom-20g.
b: This mode corresponds to scaling and feature set associated with iom-20g-b.
c: This mode corresponds to scaling and feature set associated with iom2-20g.
d: This mode corresponds to scaling and feature set associated with iom3-xp.
The force keyword forces an upgrade either from mode
a to mode
b or
d with cards provisioned as iom-20g or from mode
b to mode
c with cards provisioned as iom-20g-b.
Note that, if you are in chassis-mode d and configure an IOM type as iom2-20g and then downgrade to chassis-mode
a or
b (must specify
force keyword), a warning appears about the IOM downgrade. In this case, the IOM`s provisioned type will downgrade to iom-20g-b. Once this is done, the ASAP MDA cannot be configured. The following message appears:
*A:138.120.214.68>config>system# chassis-mode b
MINOR: CHMGR #1009 Mode change requires force - card-type iom2-20g in slot 1 would
change to iom-20g-b *A:138.120.214.68>config>system# chassis-mode b force
MINOR: CHMGR #1010 Can not change mode - mda m1-choc12-as-sfp in 10/1 not supported
when card changes to iom-20g-b
If this is the desired behavior, for example, chassis-mode d is configured and IPv6 is running, you can then downgrade to chassis-mode
a or
b if you want to disable IPv6.
*A:ALA-48# show chassis
===============================================================================
Chassis Information
===============================================================================
Name : ALA-48
Type : 7750 SR-12
Location : exit
Coordinates : N 45 58 23, W 34 56 12
CLLI code : abcdefg1234
Number of slots : 12
Number of ports : 246
Critical LED state : Off
Major LED state : Off
Minor LED state : Off
Over Temperature state : OK
Base MAC address : 14:30:ff:00:00:00
Admin chassis mode : d
Oper chassis mode : d
Hardware Data
Part number : Sim Part#
CLEI code : Sim CLEI
Serial number : sim48
Manufacture date : 01012003
Manufacturing string : Sim MfgString sim48
Manufacturing deviations : Sim MfgDeviation sim48
Time of last boot : 2007/09/24 08:15:17
Current alarm state : alarm cleared
-------------------------------------------------------------------------------
Environment Information
...
===============================================================================
*A:ALA-48#
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.
In Time Domain Multiplexed (TDM)-based networks (for example, SONET or SDH circuit- switched networks), the concept of network timing is used to prevent over-run or under-run issues where circuits are groomed (rebundled) and switched. Hardware exists in each node that takes a common clock derived from an internal oscillator, a specific receive interface or special BITS interface and provides it to each synchronous interface in the system. Usually, each synchronous interface is allowed to choose between using the chassis-provided clock or the clocking recovered from the received signal on the interface. The clocking is used to drive the transmit side of the interface. The appropriate configuration at each node which defines how interface clocking is handled must be considered when designing a network that has a centralized timing source so each interface is operating in a synchronous manner.
SR OS supports a power-supply command to configure the type and number of power supplies present in the chassis. The operational status of a power source is always displayed by the LEDs on the Control Processor/Switch Fabric Module (CP/SFM) front panel, but the power supply information must be explicitly configured in order for a power supply alarm to be generated if a power source becomes operationally disabled.
Use the CLI syntax displayed below to configure synchronization components relating to active-to-standby CPM switchover. In redundant systems, synchronization ensures that the active and standby CPMs have identical operational parameters, including the active configuration, CPM, and IOM images in the event of a failure or reset of the active CPM.
The
force-switchover command forces a switchover to the standby CPM card.
To enable automatic synchronization, either the boot-env parameter or the
config parameter must be specified. The synchronization occurs when the
admin save or
bof save commands are executed.
When the boot-env parameter of the
synchronize command is specified, the bof.cfg, primary/secondary/tertiary configuration files (.cfg and .ndx), li, and ssh files are automatically synchronized. When the
config parameter is specified, only the configuration files are automatically synchronized.
The boot-env option enables a synchronization of all the files used in system initialization.
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.
The admin redundancy synchronize command performs manual CPM synchronizations. The
boot-env parameter synchronizes the BOF, image, and configuration files in redundant systems. The
config parameter synchronizes only the configuration files in redundant systems.
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 standby command on the active or the standby CPM.
Figure 27 displays the process to provision basic system parameters.
