3 — Failure protection and redundancy provisions in ISAM
4.2 Management interfaces
The ISAM supports the following management interfaces:
• Simple Network Management Protocol (SNMP)
• Command Line Interface (CLI)
• Transaction Language 1 (TL1)
• File Transfer Protocols: TFTP, SFTP, and FTP
• Simple Network Time Protocol (SNTP)
• Secure Shell (SSH)
• System logging (Syslog)
• Debug port for troubleshooting
These management interfaces are all supported “inband”. This means that the management interface is supported on top of an Ethernet / IP stack for which the Ethernet links are the Ethernet network links as mentioned in chapter “System interface overview”. If one such network link or uplink is dedicated only for management traffic, outband management can be realized as well.
Only the CLI and TL1 management interfaces can also be realized with a dedicated RS232 interface.
Figure 4-2 Secure and insecure management interfaces Note — When a firewall is in place between the network
management stations and the ISAM network, it is required that the following UDP ports are opened on the firewall (for troubleshooting and migration reasons):
• UDP port 23 as destination port
• UDP ports 928 – 939 (928 and 939 included) as source and destination ports
Not opening these ports on the firewall may lead to a reduced or failed troubleshooting access, or a failure to perform an ISAM migration, or both.
Individual security control per management channel
CLI
4 — Management
4-4 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02
SNMP
The Simple Network Manager Protocol (SNMP) is used by network management applications like the 5520 AMS, the 5529 Statistics and Data Collector, or the 5530 Network Analyser to manage the ISAM.
Three versions of SNMP exist:
• SNMP version 1 (SNMPv1) uses a community string (that is, a plain-text password in the SNMP messages) to verify if a request may be executed or not.
This is very insecure.
• SNMP version2 (SNMPv2) has the same syntax and security level as SNMPv1, but has more commands, more error codes, different trap, and improved response
• SNMP version 3 (SNMPv3) provides authentication, privacy and administration for safe configuration and control operation. SNMPv3 also offers
transaction-by-transaction security configuration settings.
SNMPv3
The security mechanisms defined in SNMPv3 protect against threats such as masquerade, modification of information, message stream modification, and disclosure.
The SNMPv3 security mechanisms provide:
• data origin authentication
• data integrity checks
• timeliness indicator
• encryption
SNMPv3 allows for three different security levels in that messages between agent and manager can be:
• unauthenticated and unencrypted
• authenticated but unencrypted
• both authenticated and encrypted
Two security-related capabilities are defined in SNMPv3:
1 User-based Security Model (USM):
The USM provides authentication and privacy (encryption) functions and operates at the message level. In addition, the USM includes a key management capability that provides for key localization and key updates. The USM is used to authenticate entities, and provides encryption services to secure
communication between agents and managers. Each agent keeps track of the authorized user access via an internal table of user/secrets/access entries. Both authentication and encryption utilize symmetric keys, which can be generated
Note — SNMPv3 is supported by default. but also SNMPv2 and SNMPv1 messages can be processed.
4 — Management
from a password. Localization of the authentication, and encryption of keys by hashing the generated key with the ID of each agent entity is strongly
recommended.
2 View-based Access Control Model (VACM):
The VACM verifies whether a given user is allowed to access a particular MIB object and perform particular functions (MIB views: read, write or notify access). The VACM makes an access control decision on the basis of:
• the principal asking for access
• the security model and security level used for communicating the request
• the context to which access is requested
• the type of access requested (read, write, notify)
• the actual object to which access is requested.
TL1
The ISAM supports Transaction Language 1 (TL1) as management interface. This cross-vendor, cross-technology man-machine language is supported over UDP, telnet and SSH.
Please check the following documents for the full list and details of all the supported TL1 commands and events in the ISAM:
• Operations and Maintenance Using TL1 for FD 100/320Gbps NT and FX NT
• TL1 Commands and Messages Guide for FD 100/320Gbps NT and FX NT In total, maximum ten TL1 parallel sessions are supported. The following restrictions and conditions apply depending on the type of session:
• two sessions are reserved for CRAFT/Serial access
• up to five parallel TL1 sessions over Telnet (TCP) can be used
• up to five parallel TL1 sessions over SSH (TCP) can be used
• a maximum of six UDP session are supported.
In total, a maximum of ten TL1 parallel sessions are supported. When using TL1 scripts, it is recommended to strictly limit the number of active, parallel TL1 scripts to two. Anyway the TL1 response should be awaited before launching a new TL1 command to the ISAM.
An alarm is raised whenever a TL1 user logs in (successful or not), indicating the IP address, account name and timestamp of the login trial. Severity, reporting and so on of this alarm can be configured as with any other alarm. If the login was not successful, the corresponding alarm needs to be cleared manually by the operator.
To avoid an overflow of failed login alarms (for example, due to a malicious user),
4 — Management
4-6 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 The TL1 login banner is configurable.
CLI
The ISAM supports a Command Line Interface (CLI) as management interface. This interface is primarily intended as a man-machine interface for the ISAM and is supported over telnet, SHH, and using the serial interface (Craft).
Please check the following documents for the full list and details of all the supported CLI commands and events in the ISAM:
• Operations and Maintenance using CLI for FD 100/320Gbps NT and FX NT
• CLI Command Guide for FD 100/320Gbps NT and FX NT
The ISAM supports up to ten parallel CLI sessions, be it over telnet or over SSH.
There can only be 1 local Craft session.
An alarm is raised whenever a CLI user logs in (successful or not), indicating the IP address, account name and timestamp of the login trial. Severity, reporting and so on of this alarm can be configured as with any other alarm. If the login was not successful, the corresponding alarm needs to be cleared manually by the operator.
To avoid an overflow of failed login alarms (for example, due to a malicious user), a new failed login alarm will only be generated either when 3 minutes have passed since the last failed login alarm or when 90 failed logins occurred, whichever comes first.
xFTP
File Transfer Protocols
The ISAM supports 3 file transfer protocols: FTP, TFTP and SFTP.
TFTP is the simplest of the 3 file transfer protocols, but lacks reliability and security capabilities. It runs on top of UDP and does not require any username-password combination. There is also no encryption of data. The ISAM supports both a TFTP client and server. In server mode, the ISAM can handle up to 14 TFTP sessions.
FTP also lacks any encryption, but requires a username-password identification (“anonymous” access is not allowed) and runs on top of TCP/IP. The ISAM only supports an FTP client.
SFTP has been introduced as part of the SSH implementation. When the ISAM acts as an SFTP client towards an external SFTP server, the ISAM uses an
operator-configured username and password. The security settings like encryption, hashing and signature protocols can be configured by the operator via CLI or SNMPv3. The ISAM supports both an SFTP client and server. In server mode, the ISAM supports two SFTP sessions simultaneously. Also, in SFTP server mode, the
Note — The ISAM will refuse any TL1/UDP connection with a source port < 12 to protect the ISAM against malicious attacks.
4 — Management
user authentication coincides with the SSH authentication, that is, the same
username/password or username/key-pair combinations apply. This means that once the operator has been configured for CLI or TL1 with a username/password or for SSH with a username/key pair, the same username can be used for setting up an SFTP session with the ISAM.
External xFTP servers
External (software download, backup/restore…) xFTP servers can be configured in the ISAM. One and the same external server machine can be used as software download and backup/restore server, but they can be different machines as well. The servers might also be used in a redundant mode: if the first server cannot be reached, automatically the redundant one is tried. Multiple configurations are possible, depending on the situation and/or requirement of the customer.
Only one account (name, password) can be defined in the ISAM per external server:
• Even in case of multiple applications (software download, backup…) on one and the same server, only one account can be specified
• The account data is stored in encrypted format
• The account data is not readable from any management interface, not even from the SNMP manager.
In case of SFTP, only one account can be specified. This account will be used towards all external xFTP servers.
In case of FTP, up to 8 external servers/accounts can be specified, each with their own account.
In case of TFTP, no account is required, so also none (0) can be specified.
xFTP Protocol selection
The xFTP protocol to be used for example for software download/backup/restore/…
operations can be configured in the ISAM as a system-wide selection. That is, only one xFTP protocol can be selected at a time per ISAM. The selected xFTP protocol will be used for all applications requiring xFTP, independent of the used xFTP server or application.
Note however that as an FTP server is not supported in the ISAM (see section below), selecting FTP as protocol still allows to use the TFTP or SFTP server. When SFTP is selected as protocol though, the TFTP server will be disabled in the ISAM.
Likewise, when selecting TFTP as protocol, the SFTP server will be disabled in the ISAM.
xNTP
4 — Management
4-8 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 This is a system wide setting in the ISAM. While SNTP and NTP is mutually exclusive (that is, either SNTP or NTP can be enabled, but not both at the same time), the ISAM system time can always be set manually by the operator, even if SNTP or NTP is enabled.
SNTP Client
Typically, the ISAM system time is retrieved using the Simple Network Time Protocol (SNTP); the ISAM can cope with both SNTP and NTP servers, in both cases using the SNTP protocol.
On a per ISAM level, also the polling rate can be specified, applicable for all specified (S)NTP servers.
Apart from defining the (S)NTP servers, first of all SNTP must be set as the system-wide option for the ISAM. The (S)NTP server will always provide the UTC (Coordinated Universal Time): no time zone or daylight savings settings are passed over the SNTP protocol.
The (S)NTP server can be configured in the ISAM by specifying:
• The IP address of the server
• The port to be used
Up to three (S)NTP servers can be configured in the ISAM, specifying:
• The IP address of the server
• The port to be used
• The relative priority among the three possible servers
The relative priority defines which server will be polled first to get the time. If none of the time servers can be reached, even after three retries, an alarm is raised.
NTP Client
Alternatively the ISAM can also retrieve its system time using the NTP protocol (NTPv3), with up to 5 NTP servers used. Also in this case the NTP servers can be pre-configured, but no priority is to be specified as this is irrelevant in case of the NTP protocol. Note the xNTP servers need to be configured separately for the SNTP and the NTP protocol: the servers defined for the SNTP protocol will not be used by the NTP protocol and vice versa.
The following can be specified per NTP server:
• The IP address of the server
• The port to be used (default = 123)
On a per-ISAM level, also the polling rate can be specified, applicable for all specified NTP servers. If none of the servers can be reached, even after three retries, an alarm will be raised.
Also when selecting NTP to set the system time, the server will always provide the UTC time.
4 — Management
Manual setting
The ISAM system time can also be set manually by the operator. However, if SNTP or NTP is enabled (see above), the set system time will be overwritten at the next xNTP poll by the UTC time.
Time zone offset
An operator can also specify a time zone offset in the ISAM, allowing the operator to mimic “local” time. This time zone offset:
• Is taken into account once the ISAM system time is set for the first time, be it via SNTP (at the first synchronization with the (S)NTP server), via NTP (when time is set using the NTP protocol) or manually (time set by the operator)
• As long as the ISAM system time has not been set, the system time will remain fixed to January 1, 1970
• The ISAM system time (taking into account the time zone offset) is also stored in prozone and restored after a reset of the ISAM. If the time cannot be restored from prozone, the ISAM system time is set fixed to January 1, 1970 again, until the time is set, either manually or by using xNTP.
• Is independent of the fact whether xNTP is enabled or not, that is, it will also be applied when SNTP and/or NTP are disabled
• Has an allowed range of -780 to +780 minutes, with a default value of 0 minutes
• Is stored persistently
The time zone offset is applied consistently for all applications in the ISAM, including SNMP, Syslog and so on, that is the time applied by an application is always ISAM system time + time zone offset (note the default value being 0, even in case the operator did not specify any time zone offset value, the above statement still is correct).
SNTP Server towards ONT/MDU
The ISAM can also act as SNTP server towards the ONTs/MDUs. This means the ONT/MDU can retrieve its system time directly from the ISAM by using SNTP. The ISAM acts on behalf of the SNTP server in the network.
The SNTP server addresses are learned by the ONT/MDU using DHCP option 42.
Additional notes
Note — As all the management time stamping (such as alarms, syslog messages, PM, …) is based on the ISAM system time, Alcatel-Lucent highly recommends to use either SNTP or NTP instead and
discourages any manual time setting in the operational network.
4 — Management
4-10 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 ISAM, different from 0, the timestamps on the GUI will be wrong as time corrections will be applied twice (once in the ISAM with the time zone offset and again on the management application itself). The ISAM management application typically will not take into account any time (zone) correction done in the node itself. Please check on the management applications for this aspect.
• The granularity of the ISAM time information, as provided by the ISAM applications exposing ISAM time information to external applications (Syslog, 5520 AMS, OSS, …), is seconds and has following format
“yyyymmdd-hh:mm:ss”.
SSH
Secure Shell (SSH) is a protocol that provides authentication, encryption, and data integrity to secure network communications. On top of this protocol, SSH
implementations offer secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of which transmit data over the network as clear text. In addition, it offers secure data-tunneling services for TCP/IP-based applications.
SSH has a client-server architecture. The ISAM can act both as an SSH server or an SSH client; see Figure 4-3.
Figure 4-3 SSH client-server architecture in the NE
System logging
System logging (SYSLOG) allows you to trace and audit system behavior related to operator and /or system activities. System log entries are issued by actions such as CLI and TL1 user logins, but also by alarms and video CDR records, for example:
SSH client
SW&DB Secure link for the transfer
from FileServer to NE (SW&DB) File
4 — Management
With system logging, you can do the following:
• create up to 64 custom system logs that can be saved locally or to a remote server location
• create filters to determine which messages are sent to the system log files
• monitor system logs
You can configure system logs using CLI, TL1 or an EMS. Locally stored syslog files can be transferred to an external server using xFTP.
File sets
The system logging works with file sets consisting of two log files. The operator can:
• Trigger the wrap-around from file1 to file2 in order to upload a stable file1.
• Assign a name to this file set
• Specify the maximum size of the file set
Configuring system logs
You can configure the following for each system log file:
• system log filename (local only), entered using up to eight alphanumeric characters followed by a dot separator and a three-alphanumeric character extension. Example: Alrmhigh.txt
• destination server type:
• all active TL1 and CLI terminals (all-users)
• all active CLI terminals (all-CLI)
• all active TL1 terminals (all-TL1)
• single active TL1 terminal (TL1-user)
• local file (file:name:size)
• remote host (udp:port:serv-ip-addr)
• destination server address, entered as an alphanumeric host name or in standard dot format (maximum value 255.255.255.255); where 0.0.0.0 is entered for local files
• enable or disable logging
• delete a system log file
Note — The ISAM will also automatically copy file1 to file2 when file1 is full. Both actions (automatic by system / manual by operator) are performed independently of each other.
4 — Management
4-12 November 2013 Alcatel-Lucent 7302 ISAM | 7330 ISAM FTTN | 7360 ISAM FX R4.6.02 System log filters
You can configure filters to define which messages get logged to which system log files, based on the message type; by default, all message types are logged to the system log files.
Table 4-2 lists the possible message type and log severity parameters. You can select which messages are sent to specific system log files using filters and can group multiple message types.
Table 4-2 Message type and log severity parameters
Operator access to the system logs
The operator access to the log file is determined by the allowed priority (access control). Different users have different access rights to the system log file, that is, some users only have read priority, while other users with higher priority have read and write (=delete) priority.
The local log files can be retrieved via xFTP to upload to an external server. In this case the operator can access the log file only after successful xFTP authentication.
System log files are to be deleted explicitly by operator command.
Item Description Parameter
Message type Authentication actions AUTH
CLI commands CLI_CONFIG
TL1 commands TL1_CONFIG
CLI messages CLI_MSG
TL1 messages TL1_MSG
All message types ALL
Log severity Emergency EM
Alert AL
Critical CR
Error ER
Warning WN
Notice NO
Information IN
Debug DBG
Note — Besides these message types, the alarms and the errors encountered in the system are also logged in the system log files.
4 — Management
Viewing and monitoring system logs
The contents of a system log can be viewed either dynamically or statically.
The contents of a system log can be viewed either dynamically or statically.