These release notes support V2.0.1 of the ptx®/ATM software intended for use with NUMA-Q® systems. Read this document before you install and run this release of the ptx/ATM software.
The following software products are prerequisites for the ptx/ATM V2.0.1 software product:
The only network-protocol product that can be used with ptx/ATM V2.0.1 is ptx/TCP/IP V4.5.3 or later.
ptx/ATM V2.0.1 is compatible with the following ATM protocols:
UNI (User-Network Interface) 3.1 and the associated ILMI (Interim Local Management Interface)
LANE (LAN Emulation) 1.0
There are some known interoperability issues when using LANE Services hosted on Cisco Systems® edge devices and Bay Networks® ATM switches. See the section below entitled "Interoperability."
ptx/ATM V2.0.1 does not contain new features.
To install ptx/ATM V2.0.1, refer to the DYNIX/ptx and Layered Products Software Installation Release Notes.
If you are installing ptx/ATM V2.0.1 as an upgrade to ptx/ATM V1.0.x, please see the section entitled Issues for Upgrade from ptx/ATM V1.0.x to V2.0.1.
The utility /etc/netstat, which is part of ptx/TCP/IP, does not show ATM interface device names correctly. For example:
# /etc/netstat -D
loop|lo||nosnap noarp|Y|Y
pe0|fl|/dev/net/pe0|nosnap|Y|Y
clip48|fl|unknown5|noarp|Y|Y
lane48|fl|unknown65537|nosnap|Y|Y
---
loop|inet|127.0.0.1|||255.255.255.255
pe0|inet|138.95.162.48|||255.255.255.0
clip48|inet|192.168.1.48|||255.255.255.0
lane48|inet|192.168.2.48|||255.255.255.0
Note that the interface named clip48 should be named /dev/net/atmclip0 but is shown as unknown5, and the interface named lane48 should be named /dev/net/atmel0_0 but is shown as unknown65537.
Workaround 1: Display the /var/tcp/ifnets file, which contains the interfaces and their device names as they were configured during initialization of TCP. For example:
# cat /var/tcp/ifnets
S||loop|lo||nosnap noarp
2||pe0|fl|/dev/net/pe0|nosnap
2||clip48|fl|/dev/net/atmclip0|snap noarp
2||lane48|fl|/dev/net/atmel0_0|nosnap
Here, clip48 and lane48 are shown with their proper device names.
Workaround 2: Workaround 1 will not help in cases in which someone configured a new TCP interface after initialization and did not put it in the /var/tcp/ifnets file.
In such cases, look in the /dev/net directory for all possible ATM virtual interfaces, as shown in the following example:
# cd /dev/net
# ls -l atmclip? atmel*
crw-rw-rw- 1 root sys 292,1376 Feb 25 12:59 atmclip0
crwxr--r-- 1 root root 344, 1 Feb 25 12:59 atmel0_0
By comparing the interface devices in /dev/net to the list in /var/tcp/ifnets, the administrator should be able to determine the device name corresponding to any hand-created interfaces.
The -z option for the atmstat command is not supported. Therefore, when atmstat -z is executed, it does not zero out the statistics.
Workaround: None.
The three ATM configuration files (atmtab, cliptab, lanetab) reside in /var/atm/etc. The menu scripts that read these files to do automatic configuration of ATM components do not respect any comment character; therefore, you cannot place comments in these files.
Workaround: Do not attempt to place comments in the configuration files. The proper way to make changes to these files is to use the ptx/ADMIN menu system. Three .template files are provided to explain the fields in each record of the files.
A CLIP interface with more than a handful of VCs is uncommon, and by default, about 675 VCs can be displayed. The problem is that the default kernel parameter STRMSGSZ is too small to pass a structure large enough to contain all of the VC information.
Workaround: In a rare instance when you have more than 675 VCs, the kernel can be tuned (see Appendix A, "Tunable Kernel Parameters," in the ptx/ATM Administration Guide) and the kernel parameter STRMSGSZ can be adjusted to its maximum of 65535. After reconfiguring and remaking the kernel, atmadmin clip show will display all 1023 VCs.
There are some cases in which an attempt to stop or deconfigure a running ELAN will fail with the error message device busy. This is caused by other products misuse of ptx/ATM devices.
Workaround: See "Other Products' Misuse of ATM Devices."
If an ATM adapter is moved from one PCI slot to another, PTX device naming will give it a new name, and the ILMI daemon (called atm_snmpd) will fail to recognize the new adapter name.
Workaround: Device names must be corrected by the System Administrator. See the section entitled "Required Device Names for ATM Adapters."
In some cases, conversion of pvctab to cliptab will fail during an upgrade from V1.0.2 to V4.5.0.
Workaround: See the section entitled "Migration from ptx/ATM V1.0.x."
The ptx/ADMIN menus provided to configure ptx/ATM do not properly handle spaces in ELAN names.
Workaround: Do not create ELAN names with spaces in them. Underscore characters are handled properly, so use underscore if needed.
An ELAN must be configured on the ATM switch before the Sequent host can use it. If on a Sequent host you do configure an ELAN that is not present on the switch, it will be accepted and entered in the table of ELANs. For example:
% /usr/etc/atmadmin lane show
LECS (current): 47.0079.00.000000.0000.0000.0000.00a03e000001.00 ELAN UNIT LAN Type LES ATM Address ==== ==== ======== =============== => ELAN004 0 Ethernet 39.0000.00.000000.0000.0030.4b00.0020d4304b04.02 ELAN000 0 Ethernet 39.0000.00.000000.0000.0030.4b00.0020d4304b00.02 => junkxyz 0 Ethernet 00.000000000000000000000000000000000000.00
No ELAN called "junkxyz" exists on the LES/LECS (ATM switch).
If you attempt to start the ELAN, no error message will be given.
Workaround: There is no functional failure. Do not enter an ELAN in the table unless it is configured on the switch.
This problem applies to the following situation:
A LANE interface is created in ATM, attached and configured in TCP, and TCP connections are established to one or more remote hosts. That is, an ARP entry for the local host is established on remote host(s).
To see this problem, you must do the following:
ifconfig down and ifadmin detach the interface in TCP.
Delete the interface in ATM.
Create the interface in ATM. ATM software generates a different MAC address for the interface, making the ARP entry in the remote system invalid.
ifadmin attach the interface.
ifconfig up the interface.
The ATM software only begins to join the ELAN at step 4. It takes between 1 and 2 seconds to complete the ELAN join and be ready to transmit packets.
If steps 4 and 5 are done slowly enough (that is, by hand), TCP sends a gratuitous ARP that corrects the remote ARP entry, and no problem is seen.
The problem occurs if steps 4 and 5 are done too quickly, as in a script or ifconfigall. If TCP's gratuitous ARP is sent before the ELAN is fully joined, the gratuitous ARP is dropped by ATM, and the invalid ARP entry remains on the remote host.
Possible workarounds:
After an ARP timeout period, ARP will correct the problem automatically, but this can take up to 20 minutes.
Delete the ARP entry on the remote host using arp -d, thereby forcing it to do an ARP that will get a correct MAC address. This is impractical if there are many remote hosts, or the administrator does not have root access.
Delete the ARP entry on the local host, forcing it to send a new ARP that will correct any stale remote ARP entries.
After the ELAN is joined (1-2 seconds) ifconfig down and ifconfig up the interface. Since the ELAN is already joined, the gratuitous ARP will go out and correct any remote ARP entries.
For all features of ptx/ATM V2.0.0 to work correctly, ATM adapter devices must be named atmrawX, where X is a number from 0 to 15, and the X part of the name must be equal to the device number, as given in the DEVNUM column of output from /etc/dumpconf.
Note that the "unit" parameter specified while configuring or showing CLIP and LANE interfaces is also equal to the DEVNUM device number.
Because of conflicts in the device naming database, the name and device number can sometimes get out of sync and must be corrected by the System Administrator. For example, consider the following output:
# /etc/dumpconf -d
NAME CFGTYPE DEVNUM UNIT FLAGS OnBUS OnDEVICE … atmraw2 atmraw 0 0x00000002 L pci quad0 atmraw1 atmraw 1 0x00000006 L pci quad0 pe0 pe 0 0x00000001 L pci quad0
The device named atmraw1 has a DEVNUM of 1, but the device named atmraw2 has a DEVNUM of 0. This must be corrected as follows:
# /etc/devctl -n atmraw2 atmraw0
devctl: Assigned atmraw2 --> atmraw0
# /etc/dumpconf -d
NAME CFGTYPE DEVNUM UNIT FLAGS OnBUS OnDEVICE … atmraw0 atmraw 0 0x00000002 L pci quad0 atmraw1 atmraw 1 0x00000006 L pci quad0 pe0 pe 0 0x00000001 L pci quad0
You can now add the adapters atmraw0 and atmraw1 to the configuration tables, and configure CLIP or LANE interfaces on units 0 and 1, respectively.
The ptx/TCP/IP product includes a daemon called rarpd, which implements the Reverse ARP protocol. It does not work over ATM interfaces, neither CLIP nor LANE.
Other DYNIX/ptx products have components that are known to misuse ptx/ATM devices. All of the components listed in the following subsections have the no-longer-valid behavior of opening all devices found in the /dev/net directory. Under normal circumstances this does not cause any problems, but it can inhibit certain ATM operations, such as deleting a CLIP or LANE interface or resetting an ATM adapter. If this happens, the ATM operation can only be completed by killing the daemon that has the ATM devices open.
The ptx/NFS product includes a statistics-gathering daemon called rpc.statd, which may be configured at the administrator's option. The following example shows how to kill this daemon. See the ptx/NFS Administration Guide to restart it, if desired, after the ATM operation is completed.
# ps -ef | grep statd
root 5575 1 0 14:52:41 ? 0:00 /etc/rpc.statd
root 18312 11024 1 17:21:44 ttyiQ/iAQp 0:00 grep statd
# kill -9 5575
The ptx/TCP/IP product includes a daemon called mib2agt (a comms subagent) that gathers statistics on TCP/IP interfaces for access via ptx/AGENT. The following shows how to kill this daemon. Refer to the ptx/TCP/IP Administration Guide to restart it, if desired, after the ATM operation is completed.
# ps -ef | grep mib2
root 8923 1 0 22:12:11 ? 0:00 /etc/mib2agt
root 3821 3617 0 18:04:03 ttyAE/AAEi 0:00 grep mib2
# kill -9 8923
The ptx/TCP/IP product includes a daemon called rarpd, which implements the Reverse ARP protocol. It may be configured at the Administrator's option. The following example shows how to kill this daemon. See the ptx/TCP/IP Administration Guide to restart it, if desired, after the ATM operation is completed.
/etc/rarpd can be started in two ways:
by specifying a particular interface (using -d flag)
by specifying the -a flag, which will have rarpd listen on all interfaces currently up
In either case, /etc/rarpd will invoke a separate daemon for each interface it has been configured to use. The following shows how the daemon can be detected and killed. Each individual instance will need to be killed separately.
# ps -ef | grep rarpd
root 9580 8233 5 09:52:25 syscon 0:00 grep rarpd
root 9576 1 0 09:52:21 ? 0:00 /etc/rarpd -a
root 9578 1 0 09:52:21 ? 0:00 /etc/rarpd -a
root 9579 1 0 09:52:21 ? 0:00 /etc/rarpd -a
# kill -9 9576
# kill -9 9578
# kill -9 9579
The following sections describe known problems when interoperating with ATM products from other vendors.
When using ptx/ATM LANE with LANE Services running on several Cisco Systems devices, particularly Cisco 5500 and Cisco 7513, there are two known problems. These are logged in Cisco System's bug-tracking database as BugID CSCdj38583 and as case ID T30652. The solution is to install revision 12.0 (or higher) of Cisco software.
When using ptx/ATM LANE with LANE Services running on Bay Networks Centillion 50 ATM switch with MCP Version 3.2(2.7) Advanced Image, ILMI does not properly negotiate the UNI version, and the LANE configuration-reply message violates the LANE 1.0 specification. Contact IBM NUMA-Q Service and request FastPatch #250781.
The following table shows compatible DYNIX/ptx and ptx/ATM versions:
ptx/ATM |
DYNIX/ptx |
V1.0.1 |
V4.4.0 - V4.4.2 |
V1.0.2 |
V4.4.4 |
V2.0.0 |
V4.4.5 - V4.4.6 |
V2.0.1 |
V4.4.7 |
Because migration from a V1.0.x version to V2.0.1 of ptx/ATM requires a new version of DYNIX/ptx, and the upgrade of DYNIX/ptx cannot be done as a ROOT installation, the migration to ptx/ATM V2.0.1 must be done as a SCRATCH, ALT DISK DELTA, or INIT ALT DISK DELTA installation.
ptx/ATM V2.0.1 is fully upward-compatible with V2.0.0. There are no issues for migration from V2.0.0 to V2.0.1.
ptx/ATM V1.0.x supported only CLIP interfaces, and the device and interface names were identical (for example, /dev/net/faX). In ptx/ATM V2.0.1, the hardware adapters and the virtual interfaces have different names. Administrators now have the choice of using CLIP, LANE, or both, and can use either ILMI-managed ATM addresses or manually entered ATM addresses.
When ptx/ATM V2.0.1 is installed as a replacement for V1.0.x, ptx/Install attempts to convert as much of the previous configuration as possible to new formats, but some information is not computable or changeable during installation.
The end of this section shows a sample log of an installation of V2.0.1 to replace a V1.0.2 that had two adapters configured. The following subsections discuss possible issues that may come up during such a migration installation. The conditions under V1.0.x are referred to here as "old," and the conditions under V2.0.1 are referred to as "new."
The new adapter devices use the same major number as the old adapter devices even though the device name is different. On any of the installation types except ROOT, it is not possible for ptx/Install to remove the old device names before the new ones are created. This often results in the new adapter names being out of sync with their required device number. The recommended sequence is:
Reboot with the new ATM version installed.
See the "Required Device Names for ATM Adapters" section for the commands to correct the adapter device names.
Use the ptx/ADMIN menu to make sure that the correct new adapter names are entered in the configuration table (refer to the section entitled "Adapter Management" in Chapter 2 of the ptx/ATM Administration Guide).
Insert the adapters (refer to the section entitled "Insert Adapter" in Chapter 2 of the ptx/ATM Administration Guide) to download their firmware and make them operational.
See Chapter 5 of the ptx/ATM Administration Guide for information about the ILMI protocol. Since it is configured to run by default, if you have followed the steps in the previous section it will be running. But if you changed adapter names, the daemon will not know the new names; it will have to be stopped and restarted. See the section entitled "Stop ILMI Daemon and Start ILMI Daemon" in Chapter 2 of the ptx/ATM Administration Guide.
If you choose to use ILMI to manage ATM addresses, it is likely that the local addresses of each CLIP interface will change from its old value, but ptx/Install cannot compute this. Use the ptx/ADMIN menus as described in Chapter 2 "Configuring ptx/ATM: Configuring CLIP: Show Interface and PVCs," in the ptx/ATM Administration Guide, to show each CLIP interface. If its local address is wrong, use the instructions under Delete Interface from the Table and Add Interface to the Table to correct the local address.
The ATM address on each PVC is the address of the interface at the other end of the virtual circuit. Because this is the address of a different host, it probably does not change as a result of the local host's migration to ptx/ATM V2.0.1. If there is no change, usually ptx/Install will migrate it correctly from the old pvctab to the new cliptab. Check the address on each PVC using menu instructions given in the section entitled "Show Interface and PVCs" in Chapter 2 of the ptx/ATM Administration Guide. If any PVC address is wrong, use the instructions under "Remove PVCs from the Table and Add PVC's to the Table" to correct any wrong addresses.
Once local addresses of each CLIP interface and remote addresses of each PVC are correct in the configuration table, use the menu instructions given in the section entitled "Insert CLIP Device" in Chapter 2 of the ptx/ATM Administration Guide to create the CLIP interface(s) and make them active.
Since the LANE feature is new in V2.0.0, there should be no migration issues. The administrator simply has to decide whether to use LANE interfaces. Instructions for configuring are in the section entitled "Configuring ELANs" in Chapter 2 of the ptx/ATM Administration Guide.
The names of interfaces given to ptx/TCP/IP are now different. Where the old interfaces were named /dev/net/faX, the new interfaces will be named /dev/net/atmclipX and /dev/net/atmelX_Y. See the section entitled "TCP/IP Configuration" in Chapter 2 of the ptx/ATM Administration Guide for instructions to change TCP/IP configuration.
Thu Feb 25 11:05:59 EST 1999 Extracting conflict files for atm, part 1 of 1... Migrating contents of atmtab file from ptx/ATM v1.0.x Migrating contents of pvctab file from ptx/ATM v1.0.x devices= fa0 fa1 unit for device fa0 is 0 unit for device fa1 is 1 ########################## IMPORTANT ################################ After Booting on the ptx/ATM v2.0 kernel 1)Use "devctl -n" if you want to change device names of atm devices 2)Change device names in file /var/tcp/ifnets to the appropriate clip devices. 3)The records which contain invalid addresses are commented out in the new confi guration files(rectify the records). 4)The records for which the migration tool was unable to determine the device un it number are also commented out with XX as a place holder for the unit number field ( rectify them ). ########################### END OF MESSAGE ############################# The message above is also saved in the file /mnt/usr/options/atm/migrate_message Thu Feb 25 11:06:02 EST 1999 Installing ptx/ATM ./command.sh installation post commands... Accessing parent menu for new option... Updating parent menu with new option ... copying new menu file ... creating help directories ... copying help file ... Updating task file ... Addition complete. Complete. Making device nodes Appending migrated cliptab file to /mnt/var/atm/etc Appending migrated atmtab file to /mnt/var/atm/etc Thu Feb 25 11:07:31 EST 1999 atm files installed successfully
241812 - showcfg command does not recognize ATM adapter devices
242971 - atmadmin lane arp show command does not process -unit option
243993 - Wrong version string in EES messages logged by ATM utilities
244600 - Misleading error if LECS and LES addresses specified for ELAN
245110 - atmstat command has bad usage and always does a -d
245134 - System will panic if wrong device configured for TCP/IP
245481 - atmstat does not return without interrupting
245693 - The maximum setting of LANE_MAX_STREAM is only 31
246129 - elconfig fails to show LECS state for adapter 1
246131 - Selecting "a" in stop ELANs menu option is not deleting all ELANs
246229 - EES messages can fill up ktlog
246766 - Man page has wrong path for atmadmin
247164 - atmping never terminates in failure case
247289 - Unable to set network prefix with menus
247440 - PANIC: MMU fault... after using atmping on a VCI already in use
247443 - Unable to add explicit LES address with elconfig
247459 - elarp delete command gives misleading error message
247506 - LANE interfaces created with 755 mode bits
248028 - Adapter configuration menu fails to display adapter name
249211 - atmtrace does not accept full path to device
249848 - Product displays wrong version numbers
249865 - atmmon displays wrong number of VCs
241812 - showcfg command does not recognize ATM adapter devices
242971 - atmadmin lane arp show command does not process -unit option
243993 - Wrong version string in EES messages logged by ATM utilities
244600 - Misleading error if LECS and LES addresses specified for ELAN
245110 - atmstat command has bad usage and always does a -d
245134 - System will panic if wrong device configured for TCP/IP
245693 - The maximum setting of LANE_MAX_STREAM is only 31