Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

New Features

The following features have been added to CTPOS Release 7.2R1.

Support for Separate Interfaces for Management and Circuit Traffic

In certain network topologies, a segregation is required between the circuit traffic and management traffic. Therefore, separate interfaces need to be used for the management and circuit networks so that traffic segregation can be achieved at the physical interface level. Starting with CTPOS Release 7.2, support for configuring two default gateways, one for management traffic and the other for circuit traffic, is available, which enables circuit and management traffic to be segregated.

Support for Configuring NTP Authentication on CTP Devices

Network Time Protocol (NTP) is a UDP protocol for IP networks. It is a protocol designed to synchronize the clock on client machines with the clock on NTP servers. NTP uses Coordinated Universal Time (UTC) as the reference time. Starting with CTPOS Release 7.2R1, NTP authentication is supported. NTP authentication checks the authenticity of NTP server before synchronizing local time with server. This phenomenon helps you to identify secure servers from unauthorized or illegal servers. NTP authentication works with a symmetric key configured by user. The key is shared by the client and an external NTP server. The servers and clients must agree on the key to authenticate NTP packets. Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally or on purpose to masquerade as that server. It is assumed that the shared secret key is already being communicated between client and server and it is the responsibility of the server to have the shared secret keys already configured in their configuration and keys files. Also, the “trustedkey keyid” attribute must be mentioned in the server’s ntp.conf file and the NTP process (ntpd) must be started in the server side for successful authentication.

Loss of Signal Detection Capability on CTP Bundles and SAToP Bundles

Starting with CTPOS Release 7.2R1, CTP devices support the detection of a loss of signal (LOS), which denotes a physical link problem.

The T1/E1, CTP, and SAToP bundles support LOS detection and based on this signal, the run state of the bundles switches to TfFail, which initiates a software-based Y cable switchover to a redundant port. Also, for T1/E1 both-ended Y-cable redundancy configuration, only software-based Y cable link protocol is supported and hardware-based redundancy is not supported.

The way in which CTP redundancy is able to work is by using the bundle state to make decisions. To use LOS as a way to take down a RUNNING bundle, the effective method implemented is to treat a T1/E1 LOS condition exactly the same as a serial port with a bad or missing external clock. When the CTP device performs its “check external clock” function, instead of returning an automatic success on T1/E1 ports, the LOS status bit is analyzed to determine whether it is a T1/E1 port. If the LIU LOS status indicates that there is no incoming signal, then the function returns a failure, which causes the bundle to move to the TtFAIL state.

Support for Multiple Master Nodes to Associate With a Single Client Node in NetRef

Network node reference (NetRef) is an extension of the CTP adaptive port clocking. When NetRef is configured for primary or backup operation, the primary node sends clocking information to the backup node. Starting with CTPOS Release 7.2R1, you can configure up to four master modes, each of which can send their clocking information to a maximum of 10 clients or slaves and the client node can receive clocking information from the configured masters. You can configure the four master nodes using CTP Menu or the CTPView web server during Netref client configuration. As a result, a single client node can use the IP address of up to four master nodes while you configure Netref client node settings. Each master node is assigned a priority during Netref client configuration. The master node with the highest priority is assigned Priority 1, the second highest priority for the master node is Priority 2, and so on. When the highest priority master goes down or if there is some problem in the synchronization of the clock, the CTP device switches to its next highest priority master (Priority 2 master node) and so on.

Support for Unlocking Inactive User Accounts

To support the U.S. Department of Defense Joint Interoperability Test Command (JITC) requirements, when the security level of the CTP Series platforms is set as high, the JITC high security mode requires that the CTP device must automatically disable user accounts after a 35-day period of account inactivity. This requirement-standard denotes that the password of all those user accounts that do not login to the CTP device or CTPView server for the past 35 days are locked. You can unlock those user accounts in compliance with the JITC specification.

A lockout warning message is displayed only for System Administrator and CTP Administrator accounts and not for other user accounts. The lockout warning messages are recorded in the network syslog file to inform the list of those system administrator accounts, which are due to be locked in next 10 days. A script “reset_pw_lock <user>” is added on the CTP device. You can run the “reset_pw_lock <user>” script to unlock the user accounts. The “activity_check” script file that is already available on the CTP Series platforms at the /etc/cron.daily/activity_check path is enhanced to send the lockout warning messages to the network syslog.

Support for Display of Jitter and Latency in the CTP Bundle Query Output for MIB Browser

Until CTPOS Release 7.1, the CTP bundle query does not provide statistics for jitter and latency. Starting with CTPOS Release 7.2R1, jitter and latency values are displayed in the command used to query the CTP bundles. Two additional values are appended at the end of the following command to support bundle jitter and bundle latency.

[root@ctp_87 ctp_cmd 3]# cmd bndl 0 qry snmp v1;B;0;1;this is ctp bundle description of maximum length on te-0.0 port.;te-0/0;1;-1;10.216.118.88;0;0;0;10.0.0.1;1024;16.000;12.000;8.000;0;255;0x40;-1;- 1;3;20206060;20208183;0;24;88;86;0;1;10189;10089;6045;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;-1;4.145;150;

Similarly, MIB objects for bundleJitter and bundleLatency are added in ACORN-MIB used by the MIB Browser.

Jitter and latency fields are added for the CTP, SAToP, CESoPSN, and VComp bundles. However, for VComp bundles, this value is always –1, and for SAToP and CESoPSN bundles, the latency field is always –1.

Support for Full-Duplex Mode Only on NIC Ports Connected to CTP Devices

If the autonegotiation setting of the CTP Ethernet media and the far-end switch or router do not match, it is possible for the CTP Ethernet ports to be in a half-duplex state, although the duplex setting is not configurable and always assumed to be full-duplex on the CTP device. Starting with CTPOS Release 7.2, the half-duplex state at CTP network interface card (NIC) ports are acquired, regardless of the duplex setting configured on the far-end node. After the autonegotiation process is completed, if the CTP NIC cannot acquire full-duplex mode, then the interfaces are considered to be down and a log message is recorded in both the /var/log/messages directory and the syslog file stating that the interface is down due to a non-full duplex condition. You are prompted to verify the cable connection, speed, and duplex settings because the NIC link might be down.

Support for Sending Port Descriptor and Bundle Descriptor Attributes in SNMP Traps

Until CTPOS Release 7.1, SNMPv2 traps that were sent from a CTP device did not contain specific bundle descriptor information. Starting with CTPOS Release 7.2, the Bundle Descriptor and Port Descriptor fields are also passed in the SNMP traps summary transmitted to the NMS server.

Support for Disabling Direct Drive by Default on CTP Bundles

Until CTPOS Release 7.1R1, the direct drive feature is enabled by default and this functionality configuration is not displayed in the output of the bundle query. If you explicitly enabled the direct drive capability (using IP tables instead of direct drive for packet-forwarding) by using the selecting No for the Disable direct drive field in the Advanced Options screen of the Configuration window under Bundle Operations of the CTP Main Menu, bundle query displayed "NoDirDrv" when you run the bundle query from the Main Menu of CTP Menu by selecting 1) Query. Starting with CTPOS Release 7.2, the default behavior is direct-drive disabled (IP table is turned on for forwarding of packets). With default configuration, the bundle query output does not display the direct drive settings. Only if you explicitly enable the direct-drive capability, the bundle query output displays "Bndl Config Flags: DirDrv" in bundle query. CTP bundle circuits that use route redundancy and port forwarding must have direct drive disabled to allow for asymmetric routing. When direct drive is disabled, packets are forwarded based on information in the kernel’s IP stack. When direct drive is enabled, packets are forwarded directly between drivers on the local and remote CTP device.

Support for Special Characters in SNMP Location Strings

Starting with CTPOS Release 7.2R1, special characters, such as equal sign (=), semicolon (;), and spaces, are supported in SNMP location strings and SNMP contact strings, and are processed properly.

Modified: 2016-02-08