Expand Configuration and Management Manual

Expand Configuration and Management Manual
Expand Configuration
and Management
Manual
Abstract
This manual describes how to plan, configure, manage, and troubleshoot the Expand
subsystem on an HP™ NonStop™ S-series server. The Expand subsystem can
connect as many as 255 geographically dispersed HP servers to create a network with
the reliability, capacity to preserve data integrity, and potential for expansion of a single
HP server. This manual includes detailed descriptions of SCF commands and
modifiers used with the Expand subsystem.
Product Version
Expand G06
Supported Release Version Updates (RVUs)
This manual supports G06.24 and all subsequent G-series RVUs until otherwise
indicated in a new edition.
Part Number
Published
523347-008
September 2004
Document History
Part Number
Product Version
Published
523347-003
Expand G06
November 2002
523347-004
Expand G06
May 2003
523347-005
Expand G06
September 2003
523347-006
Expand G06
December 2003
523347-007
Expand G06
February 2004
523347-008
Expand G06
September 2004
Expand Configuration and
Management Manual
Glossary
Index
What’s New in This Manual xxix
Manual Information xxix
New and Changed Information
Examples
Figures
Tables
xxix
About This Manual xxxi
Who Should Use This Manual xxxi
How This Manual Is Organized xxxi
Related Documents and Online Tools
Notation Conventions xl
Abbreviations xlv
xxxv
Part I. Getting Started
1. Configuration Quick Start
Task Summary 1-1
Assumptions 1-1
Task 1: Configure and Start $NCP 1-2
Where to Find More Information About This Task 1-2
Task 2: Start the Expand Manager Process 1-2
Creating a Persistent Version of the Expand Manager Process
Where to Find More Information About This Task 1-3
Task 3: Add the Expand Line-Handler Profile(s) 1-4
Where to Find More Information About This Task 1-5
Task 4: Add the Expand Line-Handler Process 1-6
Creating a Single-Line Expand Line-Handler Process 1-6
Creating a Multi-Line Path 1-16
Where to Find More Information About This Task 1-17
Task 5: Start the Expand Line-Handler Process 1-17
Establishing a Connection 1-18
Starting an Expand Path 1-18
Starting Lines in a Multi-Line Path 1-18
Hewlett-Packard Company —523347-008
i
1-3
2. Expand Overview
Contents
2. Expand Overview
Network Transparency 2-1
Interactive Access 2-1
Programmatic Access 2-2
Expand Subsystem and the NonStop Kernel 2-2
Multiple Communications Environments 2-5
Leased and Satellite Connections 2-5
X.25 Packet-Switched Networks 2-6
Systems Network Architecture (SNA) Networks 2-6
Internet Protocol (IP) Networks 2-6
Asynchronous Transfer Mode (ATM) Networks 2-6
Fiber-Optic Cables 2-6
ServerNet Clusters 2-7
Distributed Control 2-7
Automatic Message Routing 2-7
Passthrough Routing 2-8
Best-Path Routing 2-8
Priority Routing 2-8
Fault-Tolerant Operation 2-8
Network Management 2-9
Subsystem Control Facility (SCF) 2-9
Event Management Service (EMS) 2-9
Availability Statistics and Performance (ASAP) 2-9
Measure 2-10
Compaq TSM Package 2-10
OSM Interface 2-10
Online Expansion and Reconfiguration 2-10
Network Security 2-11
Remote Passwords 2-11
Enhanced Security Techniques 2-11
3. Planning a Network Design
Selecting Line Protocols 3-1
Dedicated Lines 3-1
Satellite Connections 3-2
X.25 Connections 3-2
Systems Network Architecture (SNA) Connections 3-3
Internet Protocol (IP) Networks 3-4
Asynchronous Transfer Mode (ATM) Networks 3-5
Expand Configuration and Management Manual—523347-008
ii
3. Planning a Network Design (continued)
Contents
3. Planning a Network Design (continued)
ServerNet Connections 3-6
FOX Connections 3-7
Defining Paths Between Systems 3-7
When to Use a Single-Line Expand Line-Handler Process
When to Use a Multi-Line Path 3-8
When to Use a Multi-CPU Path 3-10
Selecting Special Features 3-12
Multipacket Frame Feature 3-12
Variable Packet Size Feature 3-13
Congestion Control Feature 3-13
Designing the Network Topology 3-13
Common Network Topologies 3-13
Topology Limitations 3-16
Creating a Network Diagram 3-16
3-8
4. Planning for ServerNet Clusters
Configuration Considerations for Expand and ServerNet Clusters 4-1
ServerNet Clusters Coexisting With FOX Rings 4-3
Considerations for ServerNet Clusters Coexisting With ServerNet/FX
Examples of ServerNet Clusters Coexisting With FOX Rings 4-4
ServerNet Clusters Coexisting With ATM or IP Networks 4-6
Considerations for ServerNet Clusters Coexisting With ATM
or IP 4-7
Examples of ServerNet Clusters Coexisting With ATM or IP 4-7
4-3
Part II. Configuring the Expand Subsystem
5. Configuration Overview
Summary of Configuration Steps 5-2
Creating a Profile 5-3
Creating Wide Area Network (WAN) Subsystem Devices
Starting the Expand Manager Process 5-4
5-4
6. Configuring the Network Control Process
Step 1: Create a Profile for $NCP
ADD Profile Command 6-1
Example 6-2
6-1
Expand Configuration and Management Manual—523347-008
iii
6. Configuring the Network Control
Process (continued)
Contents
6. Configuring the Network Control Process (continued)
Step 2: Create $NCP 6-2
ADD DEVICE Command
Considerations 6-3
Example 6-3
Step 3: Start $NCP 6-4
$NCP Modifiers 6-4
6-2
7. Configuring Direct-Connect and Satellite-Connect Lines
Required Hardware and Software 7-2
QIO Subsystem 7-3
Wide Area Network (WAN) Shared Driver 7-3
NonStop TCP/IP Process 7-3
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
Ethernet 4 ServerNet Adapter (E4SA) 7-4
Fast Ethernet ServerNet Adapter (FESA) 7-4
Gigabit Ethernet ServerNet Adapter (GESA) 7-4
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA) 7-4
ServerNet Wide Area Network (SWAN) Concentrator 7-4
Topology Considerations 7-5
Summary of Configuration Steps 7-6
Step 1: Find an Available WAN Line 7-6
Step 2: Create a Profile for the Line-Handler Process 7-7
ADD Profile Command 7-8
Examples 7-8
Step 3: Create the Line-Handler Process 7-9
ADD DEVICE Command 7-9
Considerations 7-11
Examples 7-11
Step 4: Start the Line-Handler Process 7-12
Step 5: Start the Line 7-12
Profile Modifiers 7-13
Modifiers for Special Features 7-13
PEXQSSWN and PEXQSSAT Modifiers 7-13
8. Configuring Expand-Over-IP Lines
Required Hardware and Software 8-2
QIO Subsystem 8-3
NonStop TCP/IP Process 8-4
Expand Configuration and Management Manual—523347-008
iv
7-3
Contents
8. Configuring Expand-Over-IP Lines (continued)
8. Configuring Expand-Over-IP Lines (continued)
Parallel Library TCP/IP and NonStop TCP/IPv6 Processes 8-4
Redundancy in Ethernet Adapters 8-4
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs) 8-5
Asynchronous Transfer Mode (ATM) Subsystem 8-5
E4SA, FESA, GESA, G4SA and ATM3SA 8-5
Topology Considerations 8-6
Summary of Configuration Steps 8-8
Step 1 (A): Select a Process and SUBNET for NonStop TCP/IP Use 8-9
Select a NonStop TCP/IP Process 8-9
Select a SUBNET for NonStop TCP/IP 8-9
Step 1 (A): Select a Process and SUBNET for NonStop TCP/IP Use 8-9
Select a NonStop TCP/IP Process 8-9
Select a SUBNET for NonStop TCP/IP 8-9
Creating an Ethernet SUBNET or ATM SUBNET 8-10
Step 1 (B): Select a TCPSAM Process and SUBNET for Parallel Library TCP/IP Use
8-11
Select a TCPSAM Process 8-11
Select a SUBNET for Parallel Library TCP/IP 8-12
Creating an Ethernet SUBNET 8-12
Step 1 (C): Select a Process and SUBNET for NonStop TCP/IPv6 Use 8-13
Select a SUBNET for NonStop TCP/IPv6 Use 8-13
Select a TCP6SAM Process 8-15
Creating an Ethernet Subnet 8-16
Step 2 (A): Identify an Available UDP Port Number 8-16
Step 2 (B): Identify an Available UDP Port Number for Parallel Library TCP/IP
Use 8-17
Step 2 (C): Identify an Available UDP Port Number for TCP/IPv6 Use 8-18
Step 3: Create a Profile for the Line-Handler Process 8-20
ADD Profile Command 8-20
Example 8-21
Step 4: Create the Line-Handler Process 8-21
ADD DEVICE Command 8-21
Considerations 8-24
Examples 8-25
Step 5: Start the Line-Handler Process 8-25
Step 6: Start the Line 8-26
Add a Configured Tunnel for an Expand Line 8-26
Expand Configuration and Management Manual—523347-008
v
8. Configuring Expand-Over-IP Lines (continued)
Contents
8. Configuring Expand-Over-IP Lines (continued)
Profile Modifiers 8-28
Recommended Modifiers 8-28
Modifiers for Special Features 8-29
PEXQSIP Modifiers 8-29
9. Configuring Expand-Over-ATM Lines
Required Hardware and Software 9-2
QIO Subsystem 9-2
ATM Subsystem 9-3
SLSA Subsystem 9-3
ATM 3 ServerNet Adapter (ATM3SA) 9-3
Topology Considerations 9-4
Summary of Configuration Steps 9-5
Step 1: Identify the ATM Connection 9-5
Configuring an Expand Line-Handler Process That Uses a PVC 9-6
Configuring an Expand Line-Handler Process That Uses an SVC 9-6
Configuring an Expand Line-Handler Process That Uses ATMSAP 9-9
Step 2: Create a Profile for the Line-Handler Process 9-10
ADD Profile Command 9-11
Example 9-11
Step 3: Create the Line-Handler Process 9-12
ADD DEVICE Command 9-12
Considerations 9-16
Examples 9-16
Step 4: Start the Line-Handler Process 9-17
Step 5: Start the Line 9-17
Profile Modifiers 9-17
Recommended Modifiers 9-18
Modifiers for Special Features 9-19
PEXQSATM Modifiers 9-19
10. Configuring Expand-Over-X.25 Lines
Required Hardware and Software 10-1
X25AM Line-Handler Process 10-3
QIO Subsystem 10-3
Wide Area Network (WAN) Shared Driver 10-3
NonStop TCP/IP Process 10-3
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
Expand Configuration and Management Manual—523347-008
vi
10-4
10. Configuring Expand-Over-X.25
Lines (continued)
Contents
10. Configuring Expand-Over-X.25 Lines (continued)
Ethernet 4 ServerNet Adapter (E4SA) 10-4
Fast Ethernet ServerNet Adapter (FESA) 10-4
Gigabit Ethernet ServerNet Adapter (GESA) 10-4
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA) 10-4
ServerNet Wide Area Network (SWAN) Concentrator 10-5
Topology Considerations 10-5
Summary of Configuration Steps 10-7
Step 1: Add a NAM Subdevice to the X25AM Line 10-7
Considerations 10-8
Step 2: Start the X25AM Line 10-8
Step 3: Create a Profile for the Expand-Over-X.25 Line-Handler Process
ADD Profile Command 10-9
Example 10-9
Step 4: Create the Expand-Over-X.25 Line-Handler Process 10-10
ADD DEVICE Command 10-10
Considerations 10-12
Examples 10-12
Step 5: Start the Expand-Over-X.25 Line-Handler Process 10-12
Step 6: Start the Expand-Over-X.25 Line 10-13
Profile Modifiers 10-13
Recommended Modifiers 10-13
Modifiers for Special Features 10-14
X25AM Line-Handler Process Modifiers 10-14
PEXQSNAM Modifiers 10-14
11. Configuring Expand-Over-SNA Lines
Required Hardware and Software 11-1
SNAX/APN Line-Handler Process 11-3
QIO Subsystem 11-3
Wide Area Network (WAN) Shared Driver 11-3
NonStop TCP/IP Process 11-4
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
Ethernet 4 ServerNet Adapter (E4SA) 11-4
Fast Ethernet ServerNet Adapter (FESA) 11-4
Gigabit Ethernet ServerNet Adapter (GESA) 11-5
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA) 11-5
ServerNet Wide Area Network (SWAN) Concentrator 11-5
Expand Configuration and Management Manual—523347-008
vii
11-4
10-8
Contents
11. Configuring Expand-Over-SNA
Lines (continued)
11. Configuring Expand-Over-SNA Lines (continued)
Topology Considerations 11-5
Summary of Configuration Steps 11-7
Step 1: Add the SNAX/APN Line 11-8
Considerations 11-8
Step 2: Add the LUs for the SNAX/APN Line 11-8
Considerations 11-9
Example 11-9
Step 3: Start the SNAX/APN Line 11-11
Step 4: Create a Profile for the Expand-Over-SNA Line-Handler Process
ADD Profile Command 11-11
Example 11-12
Step 5: Create the Expand-Over-SNA Line-Handler Process 11-12
ADD DEVICE Command 11-12
Considerations 11-14
Examples 11-14
Step 6: Start the Expand-Over-SNA Line-Handler Process 11-15
Step 7: Start the Expand-Over-SNA Line 11-15
Profile Modifiers 11-16
Recommended Modifiers 11-16
Modifiers for Special Features 11-16
PEXQSNAM Modifiers 11-17
12. Configuring Expand-Over-ServerNet Lines
Required Hardware and Software 12-1
Expand Manager Process ($ZEXP) 12-2
External System Area Network Manager (SANMAN) 12-2
Message Monitor Process (MSGMON) 12-2
Modular ServerNet Expansion Boards (MSEBs) 12-3
Network Access Method (NAM) 12-3
Network Control Process ($NCP) 12-3
Cluster Switch 12-3
Profile Products 12-3
ServerNet Cluster Monitor Process ($ZZSCL) 12-4
ServerNet Cluster Product 12-4
Wide Area Network (WAN) Subsystem 12-4
X and Y Fabrics 12-5
Topology Considerations 12-6
Summary of Configuration Steps 12-7
Expand Configuration and Management Manual—523347-008
viii
11-11
12. Configuring Expand-Over-ServerNet
Lines (continued)
Contents
12. Configuring Expand-Over-ServerNet Lines (continued)
Configuring a ServerNet Node 12-7
Step 1: Create a Profile for the Expand-Over-ServerNet Line-Handler Process 12-7
ADD Profile Command 12-8
Step 2: Create a Device for the Expand-Over-ServerNet Line-Handler Process 12-9
ADD DEVICE Command 12-9
Considerations 12-11
Example 12-11
Step 3: Start the Expand-Over-ServerNet Line-Handler Processes 12-12
Example 12-12
Step 4: Start the Expand-Over-ServerNet Lines 12-12
Profile Modifiers 12-13
Modifiers for Special Features 12-13
PEXPSSN Modifiers 12-13
13. Configuring Expand-Over-FOX Lines
Required Hardware and Software 13-1
FOX Monitor Process ($ZZFOX) 13-2
$ZZFOX.#X and $ZZFOX.#Y 13-2
FOX Driver 13-2
ServerNet/FX Adapters 13-2
Wide Area Network (WAN) Subsystem 13-2
Topology Considerations 13-3
Summary of Configuration Steps 13-4
Step 1: Create a Profile for the Expand-Over-FOX Line-Handler Process 13-4
ADD Profile Command 13-4
Step 2: Create a Device for the Expand-Over-FOX Line-Handler Process 13-5
ADD DEVICE Command 13-6
Considerations 13-7
Example 13-7
Step 3: Start the Expand-Over-FOX Line-Handler Processes 13-8
Step 4: Start the Expand-Over-FOX Lines 13-8
Profile Modifiers 13-8
Modifiers for Special Features 13-9
PEXQSFX Modifiers 13-9
Expand Configuration and Management Manual—523347-008
ix
14. Configuring Multi-Line Paths
Contents
14. Configuring Multi-Line Paths
Configuration Overview 14-1
Configuration Considerations 14-2
Summary of Configuration Steps 14-2
Step 1: Create a Profile for the Path-Logical Device 14-3
ADD PROFILE Command 14-3
Step 2: Create a Profile for Each Line Type 14-4
ADD PROFILE Command 14-4
Step 3: Create a Path-Logical Device 14-5
ADD DEVICE Command 14-5
Considerations 14-7
Step 4: Create the Line-Logical Devices 14-7
ADD DEVICE Command 14-7
Considerations 14-12
Step 5: Start the Path-Logical Device 14-13
Step 6: Start the Lines 14-13
Starting Specific Lines 14-13
Configuration Example 14-14
Path-Logical Device Modifiers 14-15
Modifiers for Special Features 14-15
PEXPPATH Modifiers 14-15
Line-Logical Device Modifiers 14-16
X25AM Process Modifiers 14-16
PEXQMSWN and PEXQMSAT Modifiers 14-17
PEXQMNAM Modifiers 14-18
PEXQMIP Modifiers 14-19
PEXQMATM Modifiers 14-21
Part III. Subsystem Control Facility (SCF)
15. Subsystem Control Facility (SCF) Commands
Overview of the Expand Subsystem SCF Interface
Expand Subsystem Objects 15-2
Object States 15-4
SCF Commands and Objects 15-5
Sensitive and Nonsensitive Commands 15-5
Wild-Card Support 15-6
Time Values 15-6
15-2
Expand Configuration and Management Manual—523347-008
x
Contents
15. Subsystem Control Facility (SCF)
Commands (continued)
15. Subsystem Control Facility (SCF) Commands (continued)
SCF and the WAN Subsystem 15-7
SCF and the SLSA Subsystem 15-8
ABORT Command 15-8
Considerations 15-8
Examples 15-9
ACTIVATE Command 15-9
Considerations 15-9
Example 15-9
ALTER Command 15-10
ALTER DEVICE Command 15-10
Considerations 15-10
ALTER PATH Command 15-11
Considerations 15-12
Examples 15-12
ALTER LINE Command 15-12
Considerations 15-18
Examples 15-20
ALTER PROCESS Command 15-21
Example 15-23
DELETE ENTRY Command 15-23
Considerations 15-23
Examples 15-24
INFO Command 15-24
INFO PATH Command 15-25
Considerations 15-28
INFO LINE Command 15-29
Direct-Connect and Satellite-Connect Line-Handler Processes 15-29
Expand-Over-IP Line-Handler Processes 15-34
Expand-Over-ATM Line-Handler Processes 15-39
Expand-Over-NAM, Expand-Over-ServerNet, and Expand-Over-FOX Line-Handler
Processes 15-43
Considerations 15-47
INFO PROCESS Command 15-47
CONNECTS Option 15-54
LINESET Option 15-55
NETMAP Option 15-58
PATHSET Option 15-61
RPT Option 15-62
Expand Configuration and Management Manual—523347-008
xi
Contents
15. Subsystem Control Facility (SCF)
Commands (continued)
15. Subsystem Control Facility (SCF) Commands (continued)
SUPERPATH Option 15-63
SYSTEMS Option 15-64
PRIMARY PROCESS Command 15-65
Considerations 15-66
Examples 15-66
PROBE PROCESS Command 15-67
START Command 15-69
Considerations 15-69
Examples 15-70
STATS Command 15-70
STATS PATH Command 15-70
Considerations 15-76
Examples 15-76
STATS PATH NODE Command 15-76
Examples 15-80
STATS LINE Command 15-80
Expand-Over-IP Line-Handler Processes 15-80
Expand-Over-ATM Line-Handler Processes 15-82
Expand-Over-ServerNet, Expand-Over FOX, Expand-Over-X.25, and ExpandOver-SNA Line-Handler Processes 15-84
SWAN Concentrator Lines 15-86
Considerations 15-91
Examples 15-91
STATS PROCESS Command 15-91
STATUS Command 15-95
STATUS PATH Command 15-95
Considerations 15-97
Examples 15-97
STATUS LINE Command 15-97
Considerations 15-104
Examples 15-104
STOP Command 15-105
Considerations 15-105
Examples 15-105
TRACE Command 15-106
Considerations 15-110
Examples 15-110
Expand Configuration and Management Manual—523347-008
xii
15. Subsystem Control Facility (SCF)
Commands (continued)
Contents
15. Subsystem Control Facility (SCF) Commands (continued)
VERSION Command 15-111
Considerations 15-111
Examples 15-111
VERSION PROCESS $ZEXP Command 15-112
VERSION PROCESS $NCP Command 15-112
VERSION PROCESS LINE Command 15-113
16. Tracing
Why Tracing Is Important 16-2
How to Use Tracing 16-2
Tracing $NCP 16-2
Tracing a Path or Single Line 16-2
Tracing a Line in a Multi-Line Path 16-3
Tracing Using SCF 16-3
PTrace Command Overview 16-5
FILTER Command 16-6
Considerations 16-6
Examples 16-7
FIND Command 16-7
Considerations 16-7
Examples 16-8
FROM Command 16-8
Example 16-8
HEX Command 16-8
Example 16-9
LABEL Command 16-9
Example 16-9
NEXT Command 16-9
Example 16-10
OCTAL Command 16-10
Example 16-10
OUT Command 16-10
Example 16-11
RECORD Command 16-11
Examples 16-11
SELECT Command 16-12
Expand Configuration and Management Manual—523347-008
xiii
17. Expand Modifiers
Contents
Part IV. Reference Information
17. Expand Modifiers
How to Use This Section 17-1
Required Modifiers 17-1
Modifier Dictionary 17-5
AFTERMAXRETRIES_DOWN/
AFTERMAXRETRIES_PASSIVE 17-5
ASSOCIATEDEV $dev-name 17-5
ASSOCIATESUBDEV #n 17-6
ATMSEL n 17-6
CALLTYPE_PVC/CALLTYPE_SVC/CALLTYPE_ATMSAP 17-6
CLOCKMODE_DCE/CLOCKMODE_DTE 17-7
CLOCKSPEED_600/CLOCKSPEED_1200
CLOCKSPEED_2400/CLOCKSPEED_4800
CLOCKSPEED_9600/CLOCKSPEED_19200
CLOCKSPEED_38400/CLOCKSPEED_56000
CLOCKSPEED_115200 17-7
COMPRESS_OFF/COMPRESS_ON 17-7
CONNECTTYPE_ACTIVEANDPASSIVE/
CONNECTTYPE_PASSIVE 17-8
DELAY n 17-9
DESTATMADDR n 17-9
DESTIPADDR n 17-9
DESTIPPORT n 17-10
DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF 17-10
EXTMEMSIZE n 17-10
FLAGFILL_OFF/ FLAGFILL_ON 17-10
FRAMESIZE n 17-11
INTERFACE_RS232/INTERFACE_RS422 17-11
IPVER_IPV4/IPVER_IPV6 17-11
L2DISCARDONRESET_OFF/L2DISCARDONRESET_ON 17-12
L2RETRIES n 17-12
L2TIMEOUT n 17-13
L4CONGCTRL_OFF/L4CONGCTRL_ON 17-14
L4EXTPACKETS_OFF/L4EXTPACKETS_ON 17-14
L4RETRIES n 17-14
L4SENDWINDOW n 17-15
L4TIMEOUT n 17-15
LIFNAME n 17-16
Expand Configuration and Management Manual—523347-008
xiv
17. Expand Modifiers (continued)
Contents
17. Expand Modifiers (continued)
LINEPRIORITY n 17-16
LINETF n 17-16
MAXRECONNECTS n 17-17
NEXTSYS n 17-17
OSSPACE n 17-17
OSTIMEOUT n 17-18
PATHBLOCKBYTES n 17-18
PATHPACKETBYTES n 17-19
PATHTF n 17-20
PROGRAM n 17-20
PVCNAME n 17-20
QUALITYTHRESHOLD n 17-21
QUALITYTIMER n 17-21
RETRYPROBE n 17-21
RSIZE n 17-22
RXWINDOW n 17-22
SPEED n 17-22
SPEEDK n 17-23
SRCIPADDR n 17-25
SRCIPPORT n 17-25
STARTUP_OFF/STARTUP_ON 17-25
SUPERPATH_OFF/SUPERPATH_ON 17-25
TIMERINACTIVITY n 17-26
TIMERPROBE n 17-26
TIMERRECONNECT n 17-27
TXWINDOW n 17-27
V6DESTIPADDR n 17-28
V6SRCIPADDR n 17-29
Profiles 17-29
Single-Line Expand Line-Handler Process Modifiers
Multi-Line Path Modifiers 17-32
17-29
18. Subsystem Description
Expand Subsystem Components 18-2
Expand Line-Handler Processes 18-2
Network Control Process ($NCP) 18-7
Expand Manager Process ($ZEXP) 18-7
Components Summary 18-8
Expand Configuration and Management Manual—523347-008
xv
18. Subsystem Description (continued)
Contents
18. Subsystem Description (continued)
Expand Subsystem and the OSI Reference Model 18-9
Expand Line-Handler Process Layer Functions 18-10
$NCP Layer Functions 18-12
Path Function of the Expand Subsystem 18-13
Protocol Packet Types 18-13
Packet Synchronization 18-16
Example of End-to-End Protocol Packet Exchanges 18-16
Layer 4 Send Window 18-21
Routing and Time Factors 18-22
Setting Time Factors 18-23
Negotiating Path Time Factors 18-24
Best-Path Route Selection 18-24
Network Routing Table (NRT) and Multiple Path Table (MPT) 18-25
Calculating Route Time Factors 18-27
Routing Algorithms 18-28
Multi-CPU Paths 18-31
Multi-CPU Routing Examples 18-34
Message Handling and Buffer Allocation 18-38
Outgoing Traffic Flow 18-38
Incoming Traffic Flow 18-42
Message Buffering 18-46
Global Variables 18-47
Stack 18-47
Control Blocks 18-47
Line Buffer 18-47
Buffer Pool 18-47
Shared Memory Area for QIO 18-48
Expand-to-NAM Interface 18-49
Network Access Method (NAM) Processes 18-49
Connection Establishment 18-50
Sending and Receiving Data 18-52
Expand-to-IP Interface 18-54
NonStop TCP/IP Processes 18-54
Expand-over-IP Connection Establishment 18-55
Sending and Receiving Data 18-57
Forwarding Expand-over-IP Packets to Other Expand Line-Handler
Processes 18-58
Expand Configuration and Management Manual—523347-008
xvi
18. Subsystem Description (continued)
Contents
18. Subsystem Description (continued)
Expand-to-ATM Interface 18-59
ATM Subsystem 18-59
Expand-over-ATM Connection Establishment 18-60
Sending and Receiving Data 18-62
Forwarding Expand-over-ATM Packets to Other Expand Line-Handler
Processes 18-63
Multipacket Frame Feature 18-64
Constructing Multipacket Frames 18-64
Path Initialization 18-66
Multipacket Frame Configuration 18-67
Multipacket Frame Considerations 18-67
Variable Packet Size Feature 18-68
Variable Packet Size Configuration 18-68
Variable Packet Size Considerations 18-68
Mixing Extended and Nonextended Packets 18-69
Considerations for Paths Using the Variable Packet Size Feature and the
Multipacket Frame Feature 18-70
Congestion Control Feature 18-71
Congestion Control Configuration 18-73
Congestion Control Considerations 18-73
Multi-CPU Feature 18-74
Multi-CPU Paths 18-74
Multi-CPU Configuration 18-74
Multi-CPU Considerations 18-75
Part V. Management, Tuning, and
Troubleshooting
19. Managing the Network
Accessing Network Resources 19-1
Using TACL to Manage Remote Files 19-2
Using Disk-File Names 19-2
Changing Your Default Values 19-3
Gaining Access to Remote Nodes 19-4
Setting Up Network Security 19-6
Remote File Security 19-7
Establishing Global User IDs 19-7
Expand Configuration and Management Manual—523347-008
xvii
19. Managing the Network (continued)
Contents
19. Managing the Network (continued)
Establishing Remote Passwords 19-7
Remote Process Security 19-9
Remote TACL Processes 19-9
Global Remote Passwords 19-10
Subnetwork Security 19-10
Remote Super ID User 19-11
Additional Security Techniques 19-11
Monitoring Network Activity 19-12
Displaying $NCP Information 19-12
Displaying Expand Line-Handler Process Information 19-14
Starting and Stopping Tracing 19-18
Reconfiguring the Network 19-19
Adding and Deleting Expand Line-Handler Processes 19-19
Adding and Deleting $NCP 19-19
Changing $NCP Modifiers 19-19
Changing Expand Line-Handler Process Modifiers 19-20
Changing Profiles 19-20
Adding Nodes to the Network 19-20
Removing Nodes From the Network 19-22
Changing System Names and Numbers 19-22
Controlling the Network 19-25
Starting and Stopping Expand Line-Handler Processes and $NCP
Stopping and Starting Lines and Paths 19-26
Switching Primary and Backup Processes 19-26
Rebalancing Multi-CPU Paths 19-27
20. Tuning
The Role of Network Tuning 20-1
Tuning Goals 20-1
Performance Factors 20-2
How to Use the Performance Factors Table
Multipacket Frame Size 20-3
Variable Packet Size 20-5
Application Message Size 20-7
Packet Format 20-9
Congestion Control 20-10
Layer 2 Window Size 20-11
Processor Type 20-11
20-2
Expand Configuration and Management Manual—523347-008
xviii
19-25
20. Tuning (continued)
Contents
20. Tuning (continued)
NAM Interface 20-12
Data Compression 20-13
Multi-Line Paths 20-13
Multi-CPU Paths 20-15
Network Topology 20-21
Summary of Tuning Strategies 20-22
Measuring and Mapping an Expand Network 20-22
What the Utilities Show 20-23
Using Measure 20-23
Measuring Passthrough Traffic 20-28
Setting Measurement Intervals 20-28
Tuning Examples 20-29
Example 1: Changing Packet Size 20-29
Example 2: Reducing Passthrough Traffic 20-32
21. Troubleshooting
Understanding Your Network 21-1
Collecting Network Information 21-1
EMS 21-1
SCF 21-2
Measure 21-2
ASAP 21-2
Identifying Network Problems 21-3
User Complaints 21-4
SCF Commands 21-4
Problem Check-List Summary 21-10
Resolving Specific Network Problems 21-11
$NCP Problems 21-11
Expand Line-Handler Process Problems 21-13
SWAN Concentrator Problems 21-14
WAN Subsystem Problems 21-16
Expand-Over-X.25 Problems 21-19
Expand-Over-IP Problems 21-20
Expand-Over-ATM Problems 21-25
Multi-CPU Path Problems 21-29
Reporting Network Problems 21-31
Tracing 21-31
Expand Configuration and Management Manual—523347-008
xix
21. Troubleshooting (continued)
Contents
21. Troubleshooting (continued)
Resolving Common Network Problems 21-33
Slow Response Time 21-33
Network Congestion 21-35
Node Not Available 21-35
Adding Low-Speed Lines to a Multi-Line Path
Duplicate Node 21-38
21-38
A. SCF Error Messages
Expand Error 00001
Expand Error 00002
Expand Error 00003
Expand Error 00004
Expand Error 00005
Expand Error 00006
Expand Error 00007
Expand Error 00008
Expand Error 00009
Expand Error 00010
Expand Error 00011
Expand Error 00012
Expand Error 00013
Expand Error 00014
Expand Error 00015
Expand Error 00016
Expand Error 00017
Expand Error 00018
Expand Error 00019
Expand Error 00020
Expand Error 00021
A-1
A-1
A-1
A-1
A-2
A-2
A-2
A-2
A-3
A-3
A-3
A-3
A-4
A-4
A-4
A-4
A-5
A-5
A-5
A-5
A-6
B. Moving to G-Series Systems
Online Configuration With SCF B-1
System Generation-to-SCF Considerations B-2
CONFTEXT Paragraph Information B-2
System Generation Macro and Expand Profile Comparison B-3
System Generation Modifier and Profile Modifier Comparison B-4
COUP-to-SCF Considerations B-6
Expand Configuration and Management Manual—523347-008
xx
B. Moving to G-Series Systems (continued)
Contents
B. Moving to G-Series Systems (continued)
Dynamic Configuration and Management B-6
SCF Replaces PUP and COUP B-6
System Name and System Number Attributes B-7
EMS Event Messages B-7
Viewing Event Logs B-7
Viewing Logs on a System Running a Different RVU
Event Message Changes B-7
B-7
C. Expand and WAN SCF Comparison
Command Comparison C-1
ALTER Command Comparison C-7
Modifier-to-Attribute Comparison C-7
Altering Timeout Periods C-8
Glossary
Index
Examples
Example 1-1.
Example 1-2.
Example 1-3.
Example 6-1.
Example 7-1.
Example 8-1.
Example 8-1.
Example 8-2.
Example 8-3.
Example 8-4.
Example 8-5.
Example 8-6.
Example 8-7.
Example 8-8.
Example 8-9.
Example 8-10.
Example 8-11.
Example 8-12.
SCF STATUS ADAPTER Command 1-7
SCF INFO ADAPTER Command 1-8
SCF STATUS PROCESS Command 1-9
SCF STATUS $NCP Command 6-4
SCF STATUS ADAPTER Command 7-7
SCF LISTDEV TCPIP Command 8-9
SCF LISTDEV TCPIP Command 8-9
SCF INFO SUBNET Command 8-10
SCF LISTDEV TCPIP Command 8-11
SCF INFO SUBNET Command for TCPSAM 8-12
SCF INFO SUBNET, DETAIL Command 8-14
SCF LISTDEV TCPIP Command 8-15
SCF STATUS PROCESS Command 8-17
SCF STATUS PROCESS Command for TCPSAM 8-18
SCF STATUS MON Command 8-19
\NodeB: Configure an Expand-over-TCP/IPv6 Line Using ConfiguredTunnel 8-26
Add an Expand Line to \NodeC 8-27
\NodeC: Configure an Expand-over-NonStop TCP/IPv6 Line Using
Configured-Tunnel 8-27
Expand Configuration and Management Manual—523347-008
xxi
Examples (continued)
Contents
Examples (continued)
Example 8-13.
Example 9-1.
Example 9-2.
Example 9-3.
Example 9-4.
Example 9-5.
Example 15-1.
Example 15-2.
Example 15-3.
Example 15-4.
Example 15-5.
Example 15-6.
Example 15-7.
Example 15-8.
Example 15-9.
Example 15-10.
Example 15-11.
Example 15-12.
Example 15-13.
Example 15-14.
Example 15-15.
Example 15-16.
Example 15-17.
Example 15-18.
Example 15-19.
Example 15-20.
Example 15-21.
Example 15-22.
Example 15-23.
Add an Expand Line to \NodeB 8-28
SCF INFO PVC Command 9-6
ATM Subsystem SCF INFO LINE, DETAIL Command 9-7
Expand Subsystem SCF INFO LINE, DETAIL Command for
SVC 9-8
Expand Subsystem SCF INFO LINE, DETAIL Command for
ATMSAP 9-10
Altering the CALLTYPE Modifier and LIFNAME 9-10
INFO PATH Command 15-25
INFO PATH, DETAIL Command 15-26
INFO LINE Command, Direct- and Satellite-Connect Line-Handler
Processes 15-29
INFO LINE, DETAIL Command, Direct- and Satellite-Connect LineHandler Processes 15-30
INFO LINE Command, Expand-Over-IP Line-Handler
Processes 15-34
INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler
Processes for IPv4 Lines 15-35
INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler
Processes for IPv6 Lines 15-36
INFO LINE Command, Expand-Over-ATM Line-Handler
Processes 15-39
INFO LINE, DETAIL Command, Expand-Over-ATM Line-Handler
Processes 15-40
INFO LINE Command, Expand-Over-NAM, Expand-Over-ServerNet,
and Expand-Over-FOX Line-Handler Processes 15-43
INFO LINE, DETAIL Command, Expand-Over-NAM, Expand-OverServerNet, and Expand-Over-FOX Line-Handler Processes 15-44
INFO PROCESS $NCP Command 15-50
INFO PROCESS $NCP, DETAIL Command 15-51
INFO PROCESS $NCP Command, CONNECTS Option 15-54
INFO PROCESS $NCP Command, LINESET Option 15-56
INFO PROCESS $NCP Command, NETMAP Option 15-58
INFO PROCESS $NCP Command, PATHSET Option 15-61
INFO PROCESS $NCP Command, RPT Option 15-62
INFO PROCESS $NCP Command, SUPERPATH Option 15-63
INFO PROCESS $NCP Command, SYSTEMS Option 15-64
PROBE PROCESS $NCP Command 15-68
STATS PATH Command 15-71
STATS PATH NODE Command 15-77
Expand Configuration and Management Manual—523347-008
xxii
Examples (continued)
Contents
Examples (continued)
Example 15-24. STATS LINE Command, Expand-Over-IP Line-Handler
Processes 15-80
Example 15-25. STATS LINE Command, Expand-Over-ATM Line-Handler
Processes 15-82
Example 15-26. STATS LINE Command, Expand-Over-ServerNet Line-Handler
Processes 15-84
Example 15-27. STATS LINE Command, SWAN Concentrator Lines 15-86
Example 15-28. STATS PROCESS $NCP Command, NETFLOW Option 15-93
Example 15-29. STATS PROCESS $NCP Command, LOCALFLOW Option 15-94
Example 15-30. STATUS PATH Command 15-95
Example 15-31. STATUS PATH, DETAIL Command 15-96
Example 15-32. STATUS LINE Command 15-97
Example 15-33. STATUS LINE, DETAIL Command, Direct- and Satellite-Connect LineHandler Processes 15-98
Example 15-34. STATUS LINE, DETAIL Command, LINE Object 15-100
Example 15-35. VERSION PROCESS $ZEXP Command 15-112
Example 15-36. VERSION PROCESS $NCP Command 15-112
Example 15-37. VERSION PROCESS LINE Command 15-113
Example 20-1. SYSTEM Entity Display 20-24
Example 20-2. NETLINE Entity Display 20-25
Example 20-3. LINE Entity Display 20-25
Example 20-4. PROCESS Entity Display 20-26
Example 20-5. CPU Entity Display 20-27
Example 20-6. SCF PATH STATS Display 20-29
Example 20-7. Passthrough Traffic From Measure SYSTEM Counters on
\JUICE 20-32
Example 20-8. Passthrough Traffic in a Network 20-33
Example 21-1. SCF LISTDEV Display 21-5
Example 21-2. SCF STATS Display 21-6
Example 21-3. SCF STATUS Display 21-6
Example 21-4. SCF INFO PROCESS $NCP, LINESET Display 21-7
Example 21-5. SCF INFO PROCESS $NCP, NETMAP Display 21-9
Example 21-6. SCF PROBE PROCESS, $NCP Display 21-10
Example 21-7. SCF STATUS LINE, DETAIL Command 21-20
Example 21-8. SCF STATS LINE Command (Expand-Over-IP) 21-22
Example 21-9. SCF INFO LINE, DETAIL Command (Expand-Over-IP) 21-23
Example 21-10. SCF STATUS LINE, DETAIL Command 21-25
Example 21-11. SCF STATS LINE Command (Expand-Over-ATM) 21-27
Expand Configuration and Management Manual—523347-008
xxiii
Examples (continued)
Contents
Examples (continued)
Example 21-12. SCF INFO LINE, DETAIL Command (SVC Connection)
Example 21-13. SCF PROBE Display 21-33
21-28
Figures
Figure i.
Figure 2-1.
Figure 2-2.
Figure 3-1.
Figure 3-2.
Figure 3-3.
Figure 3-4.
Figure 3-5.
Figure 4-1.
Figure 4-2.
Figure 4-3.
Figure 4-4.
Figure 4-5.
Figure 7-1.
Figure 7-2.
Figure 8-1.
Figure 8-2.
Figure 8-3.
Figure 9-1.
Figure 9-2.
Figure 9-3.
Figure 10-1.
Figure 10-2.
Figure 11-1.
Figure 11-2.
Figure 11-3.
Figure 12-1.
Figure 12-2.
Figure 13-1.
Figure 13-2.
Figure 14-1.
NonStop S-Series Configuration and Management Set xxxvi
Single-Server Process Communications 2-3
Multi-Node Process Communications 2-4
Multi-Line Path With Eight Lines and Two SWAN Concentrators 3-9
Multi-Line Path With Eight Lines and Eight SWAN Concentrators 3-10
Multi-CPU Path With Three Paths 3-11
Common Network Topologies 3-14
Network Diagram 3-17
ServerNet Cluster Inside a FOX Ring 4-5
ServerNet Cluster and FOX Ring Connected By One NonStop S-Series
System (Not Recommended) 4-6
ServerNet Clusters Connected by ATM or IP Lines 4-8
ServerNet Clusters Connected by a Single ATM or IP Line (Not
Recommended) 4-9
ServerNet Cluster Using Layered Topology With Connections to Nodes
Outside the Cluster 4-10
Direct-Connect and Satellite-Connect Connectivity Components 7-2
Direct-Connect and Satellite-Connect Line-Handler Process
Topology 7-5
Expand-Over-IP Connectivity Components with a LAN Adapter 8-2
Expand-Over-IP Connectivity Components with ATM3SA 8-3
Expand-Over-IP Line-Handler Process Topology 8-7
Expand-Over-ATM Connectivity Components 9-2
Expand-Over-ATM Line-Handler Process Topology 9-4
Expand and ATMSAP 9-9
Expand-Over-X.25 Line-Handler Process Components 10-2
Expand-Over-X.25 Line-Handler Process Topology 10-6
Expand-Over-SNA Line-Handler Process Components 11-2
Expand-Over-SNA Line-Handler Process Topology 11-6
SNAX/APN Line Configuration Example 11-10
Expand-Over-ServerNet Connectivity Components 12-1
Expand-Over-ServerNet Topology 12-6
Expand-Over-FOX Connectivity Components 13-1
Expand-Over-FOX Topology 13-3
Logical Devices for a Multi-Line Path 14-1
Expand Configuration and Management Manual—523347-008
xxiv
Figures (continued)
Contents
Figures (continued)
Figure 14-2.
Figure 15-1.
Figure 16-1.
Figure 18-1.
Figure 18-2.
Figure 18-3.
Figure 18-4.
Figure 18-5.
Figure 18-6.
Figure 18-7.
Figure 18-8.
Figure 18-9.
Figure 18-10.
Figure 18-11.
Figure 18-12.
Figure 18-13.
Figure 18-14.
Figure 18-15.
Figure 18-16.
Figure 18-17.
Figure 18-18.
Figure 18-19.
Figure 18-20.
Figure 18-21.
Figure 18-22.
Figure 18-23.
Figure 20-1.
Figure 20-2.
Figure 20-3.
Figure 20-4.
Figure 20-5.
Figure 20-6.
Figure 21-1.
Multi-Line Configuration Example 14-14
Expand Subsystem Object Hierarchy 15-2
Tracing Process Using SCF 16-4
Expand Network Environment 18-8
Expand Subsystem Protocol Layers 18-9
Normal Exchange 18-17
Lost Data 18-18
Lost Acknowledgment 18-19
Buffer Pool Failure 18-20
$NCP Exchange of Network Change Information 18-26
Sample Network With Time Factors 18-27
Routing Information With the MSH Algorithm 18-29
Routing Information With the SH Algorithm 18-30
Network Containing Normal Paths and Multi-CPU Paths 18-35
Flow of an Outgoing Local Message 18-39
Flow of Outgoing $NCP and Passthrough Traffic 18-41
Flow of Incoming Packets 18-43
Expand Line-Handler Process Data Space 18-46
Expand-Over-NAM Connection Establishment 18-50
Expand-Over-IP Packet Forwarding 18-58
Expand-Over-ATM Packet Forwarding 18-63
Multipacket Frame Feature Not Selected 18-65
Multipacket Frame Feature Selected 18-66
Mixing Extended and Nonextended Packets 18-69
Congestion Control Not Enabled 18-72
Congestion Control Not Supported 18-72
Throughput With and Without Multipacket Frames 20-4
Application Data Flow for Expand-Over-IP 20-7
CPU Matching 20-17
Pair Count Balancing for Neighbors and Non-Neighbors 20-19
Passthrough Traffic 20-21
Packet Size/Bandwidth Comparison 20-31
Network Problem Hierarchy 21-3
Expand Configuration and Management Manual—523347-008
xxv
Tables
Contents
Tables
Table i.
Table ii.
Table iii.
Table iv.
Table v.
Table vi.
Table 1-1.
Table 1-2.
Table 1-3.
Table 1-4.
Table 1-5.
Table 1-6.
Table 1-7.
Table 1-8.
Table 2-1.
Table 5-1.
Table 5-2.
Table 7-1.
Table 8-1.
Table 9-1.
Table 10-1.
Table 11-1.
Table 12-1.
Table 12-2.
Table 13-1.
Table 14-1.
Table 14-2.
Table 14-3.
Table 14-4.
Table 14-5.
Table 14-6.
Table 14-7.
Table 15-1.
Table 15-2.
Table 15-3.
Table 15-4.
Summary of Contents—Part I xxxii
Summary of Contents—Part II xxxii
Summary of Contents—Part III xxxiii
Summary of Contents—Part IV xxxiii
Summary of Contents—Part IV xxxiv
Summary of Appendices xxxiv
Profiles for Single-Line Expand Line-Handler Processes 1-4
Profiles for Line-Logical Devices 1-5
SCF ADD DEVICE Command Worksheet 1-10
SCF ADD DEVICE Syntax: Expand-Over-IP 1-11
SCF ADD DEVICE Syntax: Expand-Over-ATM 1-13
SCF ADD DEVICE Syntax: Expand-Over-X.25, Expand-Over-SNA,
Expand-Over-ServerNet, and Expand-Over-FOX 1-15
ADD DEVICE Syntax: Path-Logical Device 1-16
Subtypes for Line-Logical Devices 1-16
Online Reconfiguration Tasks 2-10
Configuration Steps 5-2
Expand Profile Templates 5-3
PEXQSSWN and PEXQSSAT Modifiers 7-13
PEXQSIP Modifiers for Expand-over-IP Lines 8-30
PEXQSATM Modifiers for Expand-over-ATM Lines 9-19
PEXQSNAM Modifiers for Expand-over-X.25 Lines 10-15
PEXQSNAM Modifiers for Expand-over-SNA Lines 11-17
Profile Products Needed for Compatibility With Other Expand
Lines 12-4
PEXPSSN Modifiers for Expand-over-ServerNet Lines 12-13
PEXQSFX Modifiers for Expand-over-FOX Lines 13-9
Profiles for Line-Logical Devices 14-5
Device Subtypes for Line-Logical Devices 14-8
PEXPPATH Modifiers 14-16
PEXQMSWN and PEXQMSAT Modifiers 14-17
PEXQMNAM Modifiers 14-18
PEXQMIP Modifiers 14-19
PEXQMATM Modifiers 14-21
Expand Commands and Object Types 15-5
Sensitive and Nonsensitive Expand SCF Commands 15-6
ALTER PATH Attributes and Corresponding Profile Modifiers 15-11
ALTER LINE Attributes and Corresponding Profile Modifiers 15-14
Expand Configuration and Management Manual—523347-008
xxvi
Tables (continued)
Contents
Tables (continued)
Table 15-5.
Table 15-6.
Table 15-7.
Table 15-8.
Table 15-9.
Table 15-10.
Table 16-1.
Table 16-2.
Table 16-3.
Table 17-1.
Table 17-2.
Table 17-3.
Table 17-4.
Table 19-1.
Table 19-2.
Table 19-3.
Table 19-4.
Table 19-5.
Table 19-6.
Table 19-7.
Table 19-8.
Table 19-9.
Table 19-10.
Table 19-11.
Table 19-12.
Table 20-1.
Table 20-2.
Table 20-3.
Table 20-4.
Table 21-1.
Table 21-2.
Table 21-3.
Table 21-4.
Table 21-5.
Table 21-6.
ALTER LINE Attributes 15-19
ALTER PROCESS Attributes and Corresponding Profile
Modifiers 15-21
Messages and Corresponding Event Numbers 15-103
$NCP Trace Records 15-108
LINE Object Trace Records 15-109
PATH Object Trace Records 15-109
PTrace Commands Summary 16-5
Number of Trace Lines Displayed 16-10
SELECT Options for Expand 16-12
Required Modifiers 17-2
Time Factor and SPEEDK Conversions 17-24
Single-Line Path Modifiers 17-29
Modifiers for Line-Logical Devices 17-32
Expand SCF Commands for $NCP Information 19-12
WAN SCF Commands for $NCP Information 19-14
Expand SCF Commands for Expand Line-Handler Processes 19-14
Subtype Values for Single-Line Line-Handler Processes 19-15
Subtype Values for Multi-Line Paths (Path and Line Logical
Devices) 19-15
WAN SCF Commands for Expand Line-Handler Process
Information 19-15
Expand SCF Commands for Line Information 19-16
Expand SCF Commands for Path Information 19-17
Expand SCF Commands for Tracing 19-18
Expand SCF Status Commands 19-21
Expand SCF Control Commands 19-26
Expand SCF Commands for Switching Processors 19-27
Performance Factors 20-2
Message Header and Packet Header Overhead 20-9
Data-Per-Packet Percentages 20-9
Summary of Tuning Strategies 20-22
LISTDEV TYPE Identifiers 21-2
Verifying Processes Using the SCF LISTDEV Command 21-4
Identifying Problems With Expand Subsystem SCF Commands 21-5
Common File-System Errors 21-7
Network Problem Check List 21-10
Identifying $NCP Problems With SCF Commands 21-11
Expand Configuration and Management Manual—523347-008
xxvii
Tables (continued)
Contents
Tables (continued)
Table 21-7.
Table 21-8.
Table 21-9.
Table 21-10.
Table 21-11.
Table 21-12.
Table 21-13.
Table 21-14.
Table 21-15.
Table 21-16.
Table 21-17.
Table B-1.
Table B-2.
Table B-3.
Table C-1.
Expand Line-Handler Process Problem-Resolution Procedures 21-13
SWAN Concentrator Problem-Resolution Check List 21-14
WAN Subsystem Problem-Resolution Check List 21-16
Expand-Over-X.25 Problem-Resolution Procedures 21-19
Detailed States (Expand-Over-IP) 21-20
Messages Displayed in the Detailed Info Field (Expand-OverIP) 21-23
Messages and Corresponding Event Numbers 21-24
Detailed States (Expand-Over-ATM) 21-25
Messages Displayed in the Detailed Info Field (Expand-OverATM) 21-28
Multi-CPU Path Problem Resolution Procedures 21-30
SCF Commands to Locate a “Downed” Path 21-36
Defining CONFTEXT Paragraph Information on G-Series Systems B-2
Relation of Expand System Generation Macros to Expand Profiles B-3
Relation of System Generation Modifiers to Profile Modifiers B-4
Expand and WAN SCF Command Comparison C-1
Expand Configuration and Management Manual—523347-008
xxviii
What’s New in This Manual
Manual Information
Expand Configuration and Management Manual
Abstract
This manual describes how to plan, configure, manage, and troubleshoot the Expand
subsystem on an HP™ NonStop™ S-series server. The Expand subsystem can
connect as many as 255 geographically dispersed HP servers to create a network with
the reliability, capacity to preserve data integrity, and potential for expansion of a single
HP server. This manual includes detailed descriptions of SCF commands and
modifiers used with the Expand subsystem.
Product Version
Expand G06
Supported Release Version Updates (RVUs)
This manual supports G06.24 and all subsequent G-series RVUs until otherwise
indicated in a new edition.
Part Number
Published
523347-008
September 2004
Document History
Part Number
Product Version
Published
523347-003
Expand G06
November 2002
523347-004
Expand G06
May 2003
523347-005
Expand G06
September 2003
523347-006
Expand G06
December 2003
523347-007
Expand G06
February 2004
523347-008
Expand G06
September 2004
New and Changed Information
Added information on the new Gigabit Ethernet 4-port ServerNet adapter (G4SA).
G4SA changes affected About This Manual, Section 1, Configuration Quick Start,
Section 2, Expand Overview, Section 7, Configuring Direct-Connect and SatelliteConnect Lines, Section 8, Configuring Expand-Over-IP Lines, Section 10, Configuring
Expand-Over-X.25 Lines, Section 11, Configuring Expand-Over-SNA Lines,
Appendix B, Moving to G-Series Systems, and the Glossary.
Expand Configuration and Management Manual—523347-008
xxix
What’s New in This Manual
New and Changed Information
Expand Configuration and Management Manual—523347-008
xxx
About This Manual
The Expand Configuration and Management Manual describes how to plan, configure,
and manage the Expand subsystem on an HP NonStop S-series server.
This manual includes
•
•
•
•
•
•
•
A configuration “quick start” that provides the basic information required to enable
you to quickly and easily define, start, and modify an Expand line-handler process
An explanation of the major features and capabilities of the Expand subsystem
A discussion of the decisions you must make before configuring the Expand
subsystem
An explanation of how to configure the Expand subsystem, including how to use
the following subsystems: ServerNet/FX adapter subsystem, X.25 Access Method
(X25AM) subsystem, SNAX/Advanced Peer Networking (SNAX/APN) subsystem,
HP NonStop Transmission Control Protocol/Internet Protocol (TCP/IP) subsystem,
HP NonStop TCP/IPv6 subsystem, Parallel Library TCP/IP, and Asynchronous
Transfer Mode (ATM) subsystem
Detailed descriptions of the contents of each of the Expand profiles
A description of the Subsystem Control Facility (SCF) interactive interface for the
Expand subsystem, including detailed reference information for each of the Expand
subsystem SCF commands
Information about how to manage, maintain, tune, and troubleshoot an Expand
network.
Who Should Use This Manual
This manual is written for anyone who is responsible for configuring, managing, or
maintaining an Expand network. Application programmers who write network
applications may also find this manual useful.
It is assumed that you are familiar with the HP NonStop™ Kernel operating system and
with basic data-communications concepts.
How This Manual Is Organized
This manual consists of five main parts, three appendices, and a glossary. The
Glossary contains technical terms and abbreviations used throughout the text.
Expand Configuration and Management Manual—523347-008
xxxi
Part I Contents
About This Manual
Part I Contents
Part I, Getting Started, consists of Sections 1 through 4. Table i summarizes the
contents of Part I.
Table i. Summary of Contents—Part I
Section
Title
Contents
1
Configuration Quick
Start
Provides the basic information required to enable
you to quickly define, start, and modify Expand linehandler process.
2
Expand Overview
Describes the Expand subsystem’s major features
and capabilities.
3
Planning a Network
Design
Discusses basic network design decisions.
4
Planning for ServerNet
Clusters
Discusses Expand and ServerNet Cluster
configuration considerations and provides topology
examples of ServerNet Clusters coexisting with
other Expand networks.
Part II Contents
Part II, Configuring the Expand Subsystem, consists of Sections 5 through 14. These
sections explain how to configure the various types of Expand line-handler processes.
Table ii summarizes the contents of Part II.
Table ii. Summary of Contents—Part II (page 1 of 2)
Section
Title
Contents
5
Configuration Overview
Provides an overview of the Expand subsystem
configuration process.
6
Configuring the Network
Control Process
Explains how to configure and start the network
control process.
7
Configuring DirectConnect and SatelliteConnect Lines
Explains how to configure and start single-line
satellite-connect and direct-connect line-handler
processes.
8
Configuring ExpandOver-IP Lines
Explains how to configure and start single-line
Expand-over-IP line-handler processes. Includes
information on NonStop TCP/IP, Parallel Library
TCP/IP, and NonStop TCP/IPv6.
9
Configuring ExpandOver-ATM Lines
Explains how to configure and start single-line
Expand-over-ATM line-handler processes.
10
Configuring ExpandOver-X.25 Lines
Explains how to configure and start single-line
Expand-over-X.25 line-handler processes.
11
Configuring ExpandOver-SNA Lines
Explains how to configure and start single-line
Expand-over-SNA line-handler processes.
Expand Configuration and Management Manual—523347-008
xxxii
Part III Contents
About This Manual
Table ii. Summary of Contents—Part II (page 2 of 2)
Section
Title
Contents
12
Configuring ExpandOver-ServerNet Lines
Explains how to configure Expand-over-ServerNet
line-handler processes.
13
Configuring ExpandOver-FOX Lines
Explains how to configure Expand-over-FOX linehandler processes.
14
Configuring Multi-Line
Paths
Explains how to configure and start multi-line paths.
Part III Contents
Part III, Subsystem Control Facility (SCF), consists of Sections 15 and 16. Table iii
summarizes the contents of Part III.
Table iii. Summary of Contents—Part III
Section
Title
Contents
15
Subsystem Control
Facility (SCF)
Commands
Describes the Subsystem Control Facility (SCF)
interface to the Expand subsystem and provides
SCF command syntax.
16
Tracing
Describes the tracing process when the SCF
TRACE command is used with commands
available in the PTrace facility.
Part IV Contents
Part IV, Reference Information, consists of Sections 17 through 18. Table iv
summarizes the contents of Part IV.
Table iv. Summary of Contents—Part IV
Section
Title
Contents
17
Expand Modifiers
Describes the modifiers that are related to the
configuration of Expand line-handler processes.
Modifiers are listed in alphabetical order.
18
Subsystem Description
Provides a high-level technical description of the
architecture and dynamics of the Expand
subsystem.
Expand Configuration and Management Manual—523347-008
xxxiii
Part V Contents
About This Manual
Part V Contents
Part V, Management, Tuning, and Troubleshooting, consists of Sections 19 through 21.
Table v summarizes the contents of Part V.
Table v. Summary of Contents—Part IV
Section
Title
Contents
19
Managing the Network
This section explains how to access network
resources, set up network security, and monitor,
reconfigure, and control an Expand network.
20
Tuning
This section provides guidelines for improving
network performance and describes the tools
available for measuring performance.
21
Troubleshooting
This section explains each of the elements of the
troubleshooting methodology and shows you how
to use it to resolve common Expand subsystem
problems.
Appendices
Table vi describes the appendices provided in this manual.
Table vi. Summary of Appendices
Appendix
Title
Contents
A
SCF Error Messages
Describes the messages issued by the Expand
SCF subsystem.
B
Moving to G-Series
Systems
Discusses the differences between G-series
versions of the Expand subsystem and D-series
versions of the Expand subsystem.
C
Expand and WAN SCF
Comparison
Compares the commands provided by the SCF
interface to the Expand subsystem with the
commands provided by the SCF interface to the
WAN subsystem.
Expand Configuration and Management Manual—523347-008
xxxiv
Related Documents and Online Tools
About This Manual
Related Documents and Online Tools
The NonStop S-series server manual set contains manuals that describe how to
configure both an entire system and individual hardware and software components,
such as peripheral devices and communications software. It includes a stem manual,
core configuration manuals, and SCF subsystem configuration manuals:
Stem manual
Describes how to prepare for and plan
configuration tasks
Core configuration manuals
Describe how to install the server operating
system and perform online configuration
SCF subsystem configuration
manuals
Describe SCF commands that you use to
configure and manage objects in a specific
subsystem
Expand Configuration and Management Manual—523347-008
xxxv
Related Documents and Online Tools
About This Manual
Figure i shows you where the Expand Configuration and Management Manual fits with
other manuals in the NonStop S-series configuration and management manual set.
Figure i. NonStop S-Series Configuration and Management Set
HP NonStop
S-Series
Planning and
Configuration
Guide
Stem Manual
Core
Configuration
Manuals
SCF
Subsystem
Configuration
Manuals
S-Series E xpand
Manuals
DSM/SCM
User’s
Guide
KernelManaged
Swap Facility
(KMSF)
Manual
SCF
Reference
Manual for
G-Series
RVUs
System
Generation
Manual for
G-Series
RVUs
SCF
Reference
Manual for
the Kernel
Subsystem
SCF
Reference
Manual for
the Storage
Subsystem
WAN
Subsystem
Configuration
and
Management
Manual
LAN
Configuration
and
Management
Manual
Expand
Configuration
and
Management
Manual
CDT 002.CDD
Expand Configuration and Management Manual—523347-008
xxxvi
Stem Manual
About This Manual
Stem Manual
•
HP NonStop S-Series Planning and Configuration Guide
This guide explains how to plan and configure NonStop S-series servers, plan and
prepare your site, create the operational environment, and make hardware and
software changes to an existing server. In addition, the guide describes the
ServerNet system area network (ServerNet SAN) and the available hardware and
software configurations for NonStop S-series servers and provides a glossary,
case studies that document sample systems, and a guide to other NonStop Sseries manuals. This guide is written for those who plan the installation,
configuration, and maintenance of the server and the software environment at a
site.
Core Configuration Manuals
•
DSM/SCM User’s Guide
This guide describes the Distributed Systems Management/Software Configuration
Manager (DSM/SCM) and explains how to configure DSM/SCM and use it to
manage and configure the software on your system.
•
Kernel-Managed Swap Facility (KMSF) Manual
This manual describes the installation, configuration, and management of the
Kernel-Managed Swap Facility (KMSF), which manages virtual memory for
NonStop servers. It describes the operation of and command syntax for NSKCOM,
the NonStop Kernel command interface to KMSF. This manual is primarily written
for those who configure, manage, and monitor kernel-managed swap space.
•
SCF Reference Manual for G-Series RVUs
This manual describes the operation of the Subsystem Control Facility (SCF) on Gseries RVUs and how it is used to configure, control, and inquire about supported
SCF subsystems. SCF is the configuration and management tool used by persons
responsible for configuring system objects or monitoring their status.
•
System Generation Manual for G-Series RVUs
This manual describes how to use the system generation program on G-series
RVUs to create a new set of operating system files. It describes the contents of the
CONFTEXT configuration file and how to run the system generation program to
create a new operating system image. This manual is intended for system
managers, analysts, and support persons responsible for installing and configuring
NonStop S-series servers.
Expand Configuration and Management Manual—523347-008
xxxvii
SCF Subsystem Configuration Manuals
About This Manual
SCF Subsystem Configuration Manuals
•
SCF Reference Manual for the Kernel Subsystem
This manual describes the Subsystem Control Facility (SCF) Kernel subsystem on
NonStop S-series servers. It also describes the configuration and management
tasks that can be performed using SCF on Kernel subsystem objects.
•
SCF Reference Manual for the Storage Subsystem
This manual describes how to use the Subsystem Control Facility (SCF) to
configure, control, and inquire about storage devices on a NonStop S-series
server. This manual is written for anyone who is responsible for configuring new
systems, changing or adding to existing system configurations, planning changes
to systems, monitoring the status of the storage subsystem, or operating a network
of distributed systems.
•
WAN Subsystem Configuration and Management Manual
This manual describes the WAN subsystem, which controls access to the
ServerNet wide area network (SWAN) concentrator. It also describes how to use
Subsystem Control Facility (SCF) commands to configure and manage the network
control process ($NCP) and Expand line-handler processes.
•
LAN Configuration and Management Manual
This manual describes how to configure, operate, and manage the ServerNet LAN
Systems Access (SLSA) subsystem. It includes detailed descriptions of the
Subsystem Control Facility (SCF) commands used with the SLSA subsystem.
Related HP Manuals
You may need to refer to the following HP manuals when configuring and managing an
Expand network:
•
ASAP Migration Guide for NSX and OMF Users
This guide introduces the Availability Statistics and Performance (ASAP) product to
users of the Network Statistics Extended (NSX) and Object Monitoring Facility
(OMF) products. It compares the features and functions of the three products to
help these users prepare for migrating current monitoring configurations to ASAP.
•
ASAP Client Manual
This manual describes using the Availability Statistics and Performance (ASAP)
Client to monitor availability, state, and performance statistics that are collected by
ASAP Server for NonStop Kernel and application resources. Reported resource
classes include internal customer Application domains, CPU, Disk, Expand, File,
Node, Process, ProcessBusy, RDF, Spooler, System, Tape, and TMF.
Expand Configuration and Management Manual—523347-008
xxxviii
Related HP Manuals
About This Manual
•
ASAP Server Manual
Availability Statistics and Performance (ASAP) is an availability, state, and
performance statistics collection infrastructure for NonStop Kernel operating
system and application resources. Reported resource classes include internal
customer Application domains, CPU, Disk, Expand, File, Node, Process,
ProcessBusy, RDF, Spooler, System, Tape, and TMF.
•
ASAP Extension Manual
This manual describes using the Availability Statistics and Performance Extension
(ASAPX) to collect, measure, view, and analyze application service-level metrics to
track the productivity, performance, and availability of applications.
•
ATM Configuration and Management Manual
This manual describes how to configure, operate, and manage the Asynchronous
Transfer Mode (ATM) subsystem on a NonStop S-series server. It includes detailed
descriptions of the Subsystem Control Facility (SCF) commands used with the
ATM subsystem.
•
Operator Messages Manual
This manual describes all messages that are distributed by the Event Management
Service (EMS). This manual provides an explanation of the cause of each
message, a discussion of its effects on the system, and suggestions for corrective
action.
•
ServerNet Cluster Manual
This manual describes the installation, configuration, and management of HP
NonStop ServerNet Cluster hardware and software.
•
ServerNet Cluster 6780 Planning and Installation Guide
This manual describes the installation and planning for the 6780 ServerNet Cluster
switch.
•
ServerNet/FX Adapter Configuration and Management Manual
This manual describes how to configure, operate, and manage the ServerNet/FX
adapter subsystem on a NonStop S-series server. It includes detailed descriptions
of the Subsystem Control Facility (SCF) commands used with the ServerNet/FX
adapter subsystem.
•
SNAX/XF and SNAX/APN Configuration and Management Manual
This manual describes how to configure the SNAX/XF and SNAX/APN
communications subsystems. It includes detailed descriptions of the Subsystem
Control Facility (SCF) commands used with the SNAX/XF and SNAX/APN
subsystems.
Expand Configuration and Management Manual—523347-008
xxxix
Guided Procedure for Configuring a ServerNet Node
About This Manual
•
TCP/IP Configuration and Management Manual
This manual describes how to configure, operate, and manage the NonStop
TCP/IP subsystem. It includes detailed descriptions of the Subsystem Control
Facility (SCF) commands used with the NonStop TCP/IP subsystem.
•
TCP/IP (Parallel Library) Configuration and Management Manual
This manual describes how to configure, operate, and manage the Parallel Library
TCP/IP subsystem. It includes detailed descriptions of the Subsystem Control
Facility (SCF) commands used with the Parallel Library TCP/IP subsystem.
•
TCP/IPv6 Configuration and Management Manual
This manual describes how to configure, operate, and manage the NonStop
TCP/IPv6 subsystem. It includes detailed descriptions of the Subsystem Control
Facility (SCF) commands used with the NonStop TCP/IP subsystem.
•
TCP/IP (Parallel Library) Migration Manual
This manual compares the configuration and management of NonStop TCP/IP and
Parallel Library TCP/IP.
•
TCP/IPv6 Migration Manual
This manual provides migration information for migrating to the NonStop TCP/IPv6
subsystem from the NonStop TCP/IP and Parallel Library TCP/IP subsystems.
•
X25AM Configuration and Management Manual
This manual describes how to configure, operate, and manage the X25AM
subsystem. It includes detailed descriptions of the Subsystem Control Facility
(SCF) commands used with the X25AM subsystem.
Guided Procedure for Configuring a ServerNet Node
Refer to the online help for the guided procedure for configuring a ServerNet node for
assistance in preparing a NonStop S-series server to become a node in a ServerNet
cluster. You use this procedure to:
•
•
Create a ServerNet cluster for the first time.
Add a node to an already configured ServerNet cluster.
Notation Conventions
Hypertext Links
Blue underline is used to indicate a hypertext link within text. By clicking a passage of
text with a blue underline, you are taken to the location described. For example:
This requirement is described under Backup DAM Volumes and Physical Disk
Drives on page 3-2.
Expand Configuration and Management Manual—523347-008
xl
General Syntax Notation
About This Manual
General Syntax Notation
The following list summarizes the notation conventions for syntax presentation in this
manual.
UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words; enter
these items exactly as shown. Items not enclosed in brackets are required. For
example:
MAXATTACH
lowercase italic letters. Lowercase italic letters indicate variable items that you supply.
Items not enclosed in brackets are required. For example:
file-name
computer type. Computer type letters within text indicate C and Open System Services
(OSS) keywords and reserved words; enter these items exactly as shown. Items not
enclosed in brackets are required. For example:
myfile.c
italic computer type. Italic computer type letters within text indicate C and Open
System Services (OSS) variable items that you supply. Items not enclosed in brackets
are required. For example:
pathname
[ ] Brackets. Brackets enclose optional syntax items. For example:
TERM [\system-name.]$terminal-name
INT[ERRUPTS]
A group of items enclosed in brackets is a list from which you can choose one item or
none. The items in the list may be arranged either vertically, with aligned brackets on
each side of the list, or horizontally, enclosed in a pair of brackets and separated by
vertical lines. For example:
LIGHTS [ ON
]
[ OFF
]
[ SMOOTH [ num ] ]
K [ X | D ] address-1
{ } Braces. A group of items enclosed in braces is a list from which you are required to
choose one item. The items in the list may be arranged either vertically, with aligned
braces on each side of the list, or horizontally, enclosed in a pair of braces and
separated by vertical lines. For example:
LISTOPENS PROCESS { $appl-mgr-name }
{ $process-name }
ALLOWSU { ON | OFF }
Expand Configuration and Management Manual—523347-008
xli
Notation for Messages
About This Manual
| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in
brackets or braces. For example:
INSPECT { OFF | ON | SAVEABEND }
… Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you
can repeat the enclosed sequence of syntax items any number of times. For example:
M address-1 [ , new-value ]...
[ - ] {0|1|2|3|4|5|6|7|8|9}...
An ellipsis immediately following a single syntax item indicates that you can repeat that
syntax item any number of times. For example:
"s-char..."
Punctuation. Parentheses, commas, semicolons, and other symbols not previously
described must be entered as shown. For example:
error := NEXTFILENAME ( file-name ) ;
LISTOPENS SU $process-name.#su-name
Quotation marks around a symbol such as a bracket or brace indicate the symbol is a
required character that you must enter as shown. For example:
"[" repetition-constant-list "]"
Item Spacing. Spaces shown between items are required unless one of the items is a
punctuation symbol such as a parenthesis or a comma. For example:
CALL STEPMOM ( process-id ) ;
If there is no space between two items, spaces are not permitted. In the following
example, there are no spaces permitted between the period and any other items:
$process-name.#su-name
Line Spacing. If the syntax of a command is too long to fit on a single line, each
continuation line is indented three spaces and is separated from the preceding line by
a blank line. This spacing distinguishes items in a continuation line from items in a
vertical list of selections. For example:
ALTER [ / OUT file-spec / ] CONTROLLER
[ , attribute-spec ]...
Notation for Messages
The following list summarizes the notation conventions for the presentation of
displayed messages in this manual.
Expand Configuration and Management Manual—523347-008
xlii
Notation for Messages
About This Manual
Bold Text. Bold text in an example indicates user input entered at the terminal. For
example:
ENTER RUN CODE
?123
CODE RECEIVED:
123.00
The user must press the Return key after typing the input.
Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or
returned exactly as shown. For example:
Backup Up.
lowercase italic letters. Lowercase italic letters indicate variable items whose values are
displayed or returned. For example:
p-register
process-name
[ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For
example:
Event number = number [ Subject = first-subject-value ]
A group of items enclosed in brackets is a list of all possible items that can be
displayed, of which one or none might actually be displayed. The items in the list might
be arranged either vertically, with aligned brackets on each side of the list, or
horizontally, enclosed in a pair of brackets and separated by vertical lines. For
example:
LDEV ldev [ CU %ccu | CU %... ] UP [ (cpu,chan,%ctlr,%unit) ]
{ } Braces. A group of items enclosed in braces is a list of all possible items that can be
displayed, of which one is actually displayed. The items in the list might be arranged
either vertically, with aligned braces on each side of the list, or horizontally, enclosed in
a pair of braces and separated by vertical lines. For example:
LBU { X | Y } POWER FAIL
process-name State changed from old-objstate to objstate
{ Operator Request. }
{ Unknown.
}
| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in
brackets or braces. For example:
Transfer status: { OK | Failed }
Expand Configuration and Management Manual—523347-008
xliii
Notation for Subnet
About This Manual
% Percent Sign. A percent sign precedes a number that is not in decimal notation. The %þ
notation precedes an octal number. The %Bþ notation precedes a binary number. The
%H þnotation precedes a hexadecimal number. For example:
%005400
P=%p-register E=%e-register
Notation for Subnet
The following describes the notation conventions for SUBNET and subnet used in this
manual.
UPPERCASE LETTERS. Uppercase letters indicate the NonStop TCP/IP, Parallel Library
TCP/IP, or NonStop TCP/IPv6 subsystem SCF SUBNET object. For example:
Port A is identified by logical interface (LIF) 018, which uses a SUBNET on the
TCP/IP process named $ZB018 in processor 0.
lowercase letters. Lowercase letters indicate the general networking term for subnet. For
example:
Multicast datagrams that have a Time-To-Live (TTL) value of 1 are forwarded only
to hosts on the local subnet.
Change Bar Notation
Change bars are used to indicate substantive differences between this edition of the
manual and the preceding edition. Change bars are vertical rules placed in the right
margin of changed portions of text, figures, tables, examples, and so on. Change bars
highlight new or revised information. For example:
The message types specified in the REPORT clause are different in the COBOL85
environment and the Common Run-Time Environment (CRE).
The CRE has many new message types and some new message type codes for
old message types. In the CRE, the message type SYSTEM includes all messages
except LOGICAL-CLOSE and LOGICAL-OPEN.
Expand Configuration and Management Manual—523347-008
xliv
Abbreviations
About This Manual
Abbreviations
The following list defines abbreviations and acronyms used in this guide. Both industrystandard terms and HP terms are included.
API. Application Program Interface
ATM. Asynchronous Transfer Mode
ATM3SA. ATM 3 ServerNet Adapter
ASAP. Availability Statistics and Performance
CAP. Communications Access Protocol
CLIP. Communications Line Interface Processor
ConMgr. Concentrator Manager Process
DLC. Data Link Control
DSM. Distributed Systems Management
DV. Distance Vector
E4SA. Ethernet 4 ServerNet Adapter
ETF. Effective Time Factor
EMS. Event Management Service
FCSA. Fibre-Channel ServerNet Adapter
FESA. Fast Ethernet ServerNet Adapter
FOX. Fiber Optic Extension
FTP. File Transfer Protocol
G4SA. Gigabit Ethernet ServerNet Adapter
GESA. Gigabit Ethernet ServerNet Adapter
HC. Hop Count
HDLC. High-Level Data Link Control
IEEE. Institute of Electrical and Electronics Engineers
IOAM. Input/Output Adapter Module
Expand Configuration and Management Manual—523347-008
xlv
Abbreviations
About This Manual
IOP. Input-Output Process
IP.
Internet Protocol
LAN. Local Area Network
LNP. Logical Network Partitioning
LU. Logical Unit
MPT. Multiple Path Table
MSEB. Modular ServerNet Expansion Board
MSH. Modified Split Horizon
NAM. Network Access Method
NCP. Network Control Process
NRT. Network Routing Table
OOS. Out Of Sequence
OSI. Open Systems Interconnection
OSS. Open System Services
PIN. Process Identification Number
PU. Physical Unit
PVC. Permanent Virtual Circuit
RPT. Reverse Pairing Table
SAN. System Area Network
SCF. Subsystem Control Facility
SCP. Subsystem Control Point
SEB. ServerNet Expansion Board
SH. Split Horizon
SLSA. ServerNet LAN Systems Access
SNA. Systems Network Architecture
SVC. Switched Virtual Circuit
Expand Configuration and Management Manual—523347-008
xlvi
Abbreviations
About This Manual
SWAN. ServerNet Wide Area Network
TACL. HP Tandem Advanced Command Language
TCP/IP. Transmission Control Protocol/Internet Protocol
TF.
Time Factor
TFTP. Trivial File Transfer Protocol
UDP. User Datagram Protocol
WAN. Wide Area Network
X25AM. X.25 Access Method
$NCP. Network Control Process name
$ZEXP. Expand Manager Process name
$ZNET. Subsystem Control Point process name
$ZNUP. Network Utility Process name
$ZPM. Persistence Manager Process name
$ZZFOX. FOX Monitor Process name
$ZZKRN. Kernel Subsystem Manager Process name
$ZZLAN. SLSA Subsystem Manager Process name
$ZZSCL. ServerNet Monitor Process name
$ZZWAN. WAN Subsystem Manager Process name
Expand Configuration and Management Manual—523347-008
xlvii
Abbreviations
About This Manual
Expand Configuration and Management Manual—523347-008
xlviii
Part I. Getting Started
Part I consists of the following sections, which describe the Expand subsystem’s major
features, discuss basic network design issues, and provide the basic information
required to enable you to quickly define and start Expand line-handler processes:
Section 1
Configuration Quick Start
Section 2
Expand Overview
Section 3
Planning a Network Design
Section 4
Planning for ServerNet Clusters
Expand Configuration and Management Manual—523347-008
Part I. Getting Started
Expand Configuration and Management Manual—523347-008
1
Configuration Quick Start
This section provides the basic information required to enable you to quickly and easily
define and start an Expand line-handler process. This procedure requires that you use
the default values provided by the Expand subsystem for most configuration modifiers.
If you want a customized configuration, or if you want to change your configuration,
you must refer to the sections provided in Part II, Configuring the Expand Subsystem.
Task Summary
Configuring and starting an Expand line-handler process involves the following tasks:
•
•
•
•
•
Task 1: Configure and Start $NCP on page 1-2
Task 2: Start the Expand Manager Process on page 1-2
Task 3: Add the Expand Line-Handler Profile(s) on page 1-4
Task 4: Add the Expand Line-Handler Process on page 1-6
Task 5: Start the Expand Line-Handler Process on page 1-17
Assumptions
At the beginning of this procedure, the NonStop S-series server is assumed to be in
the following state:
•
•
•
•
•
•
•
The default software configuration provided by HP manufacturing is running.
The initial OSM or TSM configuration is complete.
The ServerNet LAN Systems Access (SLSA) subsystem has been configured and
started and an Ethernet 4 ServerNet adapter (E4SA), Fast Ethernet ServerNet
adapter (FESA), Gigabit Ethernet ServerNet adapter (GESA), or Gigabit Ethernet
4-port ServerNet adapter (G4SA) has been installed and started.
A NonStop TCP/IP process and Ethernet SUBNET have been created and started.
The WAN manager process ($ZZWAN) has been created and started.
The WAN subsystem Concentrator Manager (ConMgr), WANBoot, TFTP server,
and the SNMP trap multiplexer processes have been created and started.
The ServerNet wide area network (SWAN) concentrator has been installed,
configured, and started and has an available WAN line.
Expand Configuration and Management Manual—523347-008
1 -1
Configuration Quick Start
Task 1: Configure and Start $NCP
Task 1: Configure and Start $NCP
The network control process ($NCP) is responsible for initiating and terminating serverto-server connections and maintaining network-related system tables, including routing
information. $NCP must be running at every node in the Expand network before
Expand lines can be started.
To configure and start the network control process, perform the following steps:
1. Log onto the NonStop S-series server using the super ID (SUPER.SUPER) and
enter the correct password at the Password: prompt.
> LOGON SUPER.SUPER
Password:
2. At the TACL prompt, start the Subsystem Control Facility (SCF).
> SCF
3. Create a profile for the network control process.
-> ADD PROFILE $ZZWAN.#PEXPNCP, FILE $SYSTEM.SYS00.PEXPNCP
4. Create the network control process.
-> ADD DEVICE $ZZWAN.#NCP, IOPOBJECT $SYSTEM.SYS00.NCPOBJ, &
PROFILE PEXPNCP, CPU 0, ALTCPU 1, TYPE (62,6), RSIZE 1
5. Start the network control process
-> START DEVICE $ZZWAN.#NCP
Note. Do not log off or exit from SCF after completing this task. The remaining tasks in this
procedure require the use of SCF commands and super ID privileges.
Where to Find More Information About This Task
Section 6, Configuring the Network Control Process
Task 2: Start the Expand Manager Process
1. The Expand subsystem requires that the Expand manager process ($ZEXP) be
running during network operation. To start the Expand manager process, enter the
following command at the TACL prompt:
> RUN $SYSTEM.SYSnn.OZEXP / NAME $ZEXP, PRI 180, NOWAIT,&
CPU primary / backup
where primary is the number of the processor where the primary process will run
and backup is the processor where the backup process will run.
Expand Configuration and Management Manual—523347-008
1 -2
Configuration Quick Start
Creating a Persistent Version of the Expand
Manager Process
2. You can also start the Expand manager process at system startup by including the
following command in the system startup file:
OZEXP / NAME $ZEXP, OUT $ZHOME, PRI 180, NOWAIT, &
CPU primary / backup
3. To verify that the process is started, enter the TACL process-pair directory (PPD)
command at the TACL prompt:
> PPD $ZEXP
Creating a Persistent Version of the Expand Manager Process
Rather than manually create and start (and restart after processor halts) the Expand
manager you should create a persistent generic version.
1. Use the Kernel subsystem SCF ADD PROCESS command to add the $ZEXP
process to the Expand subsystem:
-> ADD PROCESS $ZZKRN.#ZEXP, NAME $ZEXP, AUTORESTART 1, &
PROGRAM $SYSTEM.SYSTEM.OZEXP, PRIMARYCPU 4, BACKUPCPU 7, &
STARTMODE SYSTEM, STARTUPMSG “<bckp-cpu>”
2. To start the Expand Manager Process, use the Kernel subsystem SCF START
PROCESS command, as follows:
-> START PROCESS $ZZKRN.#ZEXP
3. To verify that the process has started successfully, enter the following TACL
command:
> STATUS $ZEXP
Where to Find More Information About This Task
•
•
•
Section 5, Configuration Overview
For details about the Kernel SCF commands and the creation of generic
processes, consult the SCF Reference Manual for the Kernel Subsystem.
If you are using SCF on a G-Series system for the first time, you are advised to
consult the SCF Reference Manual for G-Series RVUs for information on how to
modify and save modifications to a configuration file.
Expand Configuration and Management Manual—523347-008
1 -3
Task 3: Add the Expand Line-Handler Profile(s)
Configuration Quick Start
Task 3: Add the Expand Line-Handler Profile(s)
HP provides profiles, which contain modifiers and default modifier values, for each type
of Expand line-handler process. You can use these profiles to create profiles for your
Expand line-handler processes. To add a profile for an Expand line handler, perform
the following steps:
Note. To add a Expand line-handler process that is part of a multi-CPU path, perform either
Step 1 or Step 2 as described below.
1. If you want add a single-line Expand line-handler process, perform the following
steps. If you want to add a multi-line path, got to Step 2.
a. Add a profile to the WAN subsystem for the type of Expand line-handler
process that you want to configure.
-> ADD PROFILE $ZZWAN.#name, &
FILE $SYSTEM.SYS00.profile_name
where name is the name you want to assign to the profile and profile_name
is the name of a profile listed in Table 1-1.
Table 1-1. Profiles for Single-Line Expand Line-Handler Processes
Profile Name
Type of Single-Line Expand Line-Handler Process
PEXQSSWN
Direct-connect
PEXQSSAT
Satellite-connect
PEXQSNAM
Expand-over-NAM
PEXQSIP
Expand-over-IP
PEXQSATM
Expand-over-ATM
PEXPSSN
Expand-over-ServerNet
PEXQSFX
Expand-over-FOX
2. If you want to add a multi-line path, perform the following steps:
a. Add a profile to the WAN subsystem for the path-logical device using the
PEXPPATH profile:
-> ADD PROFILE $ZZWAN.#name, FILE $SYSTEM.SYS00.PEXPPATH
where name is the name you want to assign to the profile.
b. Add a profile for each type of line in the multi-line path:
-> ADD PROFILE $ZZWAN.#name2, &
FILE $SYSTEM.SYS00.profile_name
where name2 is the name you want to assign to the profile and
profile_name is the name of a profile listed in Table 1-2,
Expand Configuration and Management Manual—523347-008
1 -4
Where to Find More Information About This Task
Configuration Quick Start
Table 1-2. Profiles for Line-Logical Devices
Profile Name
Type of Line-Logical Device
PEXQMSWN
Direct-connect
PEXQMSAT
Satellite-connect
PEXQMNAM
Expand-over-NAM
PEXQMATM
Expand-over-ATM
PEXQMIP
Expand-over-IP
The following rules apply when creating profiles for lines in a multi-line path:
•
•
•
You can configure a maximum of eight lines in a multi-line path.
The lines in a multi-line path can be all the same type or they can be any
combination of dedicated lines, X.25 connections, and SNAX connections. You
cannot mix satellite-connect, Expand-over-ATM, and Expand-over-IP lines with
other line types. Expand-over-ServerNet and Expand-over-FOX lines cannot be
part of a multi-line path.
You must create a profile for each type of line that will be in a multi-line path. Lines
of the same type can share the same profile.
Where to Find More Information About This Task
Section 7, Configuring Direct-Connect and Satellite-Connect Lines
Section 8, Configuring Expand-Over-IP Lines
Section 9, Configuring Expand-Over-ATM Lines
Section 10, Configuring Expand-Over-X.25 Lines
Section 11, Configuring Expand-Over-SNA Lines
Section 12, Configuring Expand-Over-ServerNet Lines
Section 13, Configuring Expand-Over-FOX Lines
Section 14, Configuring Multi-Line Paths
Expand Configuration and Management Manual—523347-008
1 -5
Configuration Quick Start
Task 4: Add the Expand Line-Handler Process
Task 4: Add the Expand Line-Handler Process
The Expand subsystem supports a variety of different protocols and communications
methods to enable you to connect systems together in local area network (LAN) and
wide area network (WAN) topologies. The following types of Expand line-handler
processes can be configured:
•
•
•
•
•
•
•
•
Direct-connect
Satellite-connect
Expand-over-IP
Expand-over-ATM
Expand-over-X.25
Expand-over-SNA
Expand-over-ServerNet
Expand-over-FOX
You can configure an Expand line-handler process to manage a single line Expand
line-handler process, or you can configure a multi-line path. A multi-line path can
contain up to eight parallel lines. You can also configure an Expand line-handler
process to be part of a multi-CPU path.
Creating a Single-Line Expand Line-Handler Process
This subsection explains how to create a single-line Expand line-handler process. If
you want to create a multi-line path, refer to Creating a Multi-Line Path on page 1-16.
Note. How to configure a single-line Expand line-handler process to be part of a multi-CPU
path is described in Step 6.
Satellite-Connect and Direct-Connect Line-Handler
Processes
To create a single-line satellite-connect or direct-connect line-handler process, perform
the following steps:
1. Find an available WAN line on a SWAN concentrator attached to your server.
-> STATUS ADAPTER $ZZWAN.#*, SUB ALL
Available lines are indicated in the resulting display by the word FREE in the
command display. Example 1-1 shows a STATUS ADAPTER display. An available
line is indicated on line 1 of CLIP 1 on the SWAN concentrator named S01. This
information is shown in boldface type.
Expand Configuration and Management Manual—523347-008
1 -6
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
Example 1-1. SCF STATUS ADAPTER Command
WAN Manager STATUS ADAPTER for ADAPTER
State........... STARTED
\NODEA.$ZZWAN.#S01
Number of clips. 3
Clip 1 status : CONFIGURED
Clip 2 status : CONFIGURED
Clip 3 status : CONFIGURED
WAN Manager STATUS SERVER for CLIP
State :......... STARTED
\NODEA.$ZZWAN.#S01.1
Path A..........: CONFIGURED
Path B..........: CONFIGURED
Number of lines. 2
Line............ 0
Line............ 1
: $X25A
: FREE
WAN Manager STATUS PATH for PATH
State :......... STARTED
\NODEA.$ZZWAN.#S01.1.A
MEDIA TYPE...... ETHERNET
MEDIA ADDRESS... %H000000000000
2. Using the information obtained from the SCF STATUS ADAPTER command,
record the following information in the SCF ADD DEVICE Command Worksheet on
page 1-10:
a. The name of the SWAN concentrator with the available WAN line in the
concname field. (For example: S01.)
b. The CLIP (1, 2, or 3) containing the available WAN line in the clipnum field.
(For example: 1.)
c. The line number of the available WAN line in the linenum field. (For example,
1.)
d. Record the configured path that you prefer to use (A or B) in the pathname
field. (For example: A.) Configured paths are indicated by the word
CONFIGURED following the path name in the SCF STATUS ADAPTER
command display.
Expand Configuration and Management Manual—523347-008
1 -7
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
3. Using the name of the SWAN concentrator with the available WAN line from
Step 2a, determine the names of the preferred and alternate NonStop TCP/IP
processes configured for the SWAN concentrator.
-> INFO ADAPTER $ZZWAN.#concname
The command display shows the names of the preferred and alternate NonStop
TCP/IP processes (or TCPSAM or TCP6SAM processes for Parallel Library
TCP/IP or NonStop TCP/IPv6 environments) in the *TCPIP Name and
*ALTTCPIP Name fields, respectively. An example of an SCF INFO ADAPTER
command is shown in Example 1-2. The preferred and alternate NonStop TCP/IP
process names are shown in boldface type.
Example 1-2. SCF INFO ADAPTER Command
WAN Manager Detailed Info Adapter \NODEA.$ZZWAN.#S01
*TrackId...........
*ALTTCPIP Name.....
KERNELCODE.........
*SNMPCODE..........
*HOSTIP Address....
ALTHOSTIP Address..
GATEWAYIP Addr.....
ALTGATEWAYIP Addr..
SUBNETMASK.........
ALTSUBNETMASK......
XR4T7D
*TCPIP Name....... $ZB01C
$ZB018
Concentrator Type. SYNC
$SYSTEM.CSS00.C7953P00
$SYSTEM.CSS00.C7849P00
172.016.035.117
172.016.045.119
000.000.000.000
000.000.000.000
%HFFFFFF00
%HFFFFFF00
4. Using the names of the preferred and alternate NonStop TCP/IP, TCPSAM, or
TCP6SAM processes shown in the SCF INFO ADAPTER display, determine in
which processors the preferred and alternate processes are running.
-> STATUS PROCESS $tcip_process_preferred
-> STATUS PROCESS $tcip_process_alternate
The command display shows the number of the processor where the NonStop
TCP/IP, TCPSAM, or TCP6SAM process is running in the PPID field. The first
number in parentheses is the processor number. An example of two SCF STATUS
PROCESS commands is shown in Example 1-3. The processor numbers are
shown in boldface type.
Expand Configuration and Management Manual—523347-008
1 -8
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
Example 1-3. SCF STATUS PROCESS Command
-> STATUS PROCESS $ZB018
TCPIP Status process \NODEA.$ZB018
Status: Started
PPID............. ( 0,319)
BPID................ ( 1,292)
Proto
TCP
TCP
TCP
Faddr
0.0.0.0
0.0.0.0
0.0.0.0
Status
LISTEN
LISTEN
LISTEN
Laddr
0.0.0.0
0.0.0.0
0.0.0.0
Lport
ftp
finger
echo
Fport
*
*
*
SendQ
0
0
0
RecvQ
0
0
0
-> STATUS PROCESS $ZB01C
TCPIP Status process \NODEA.$ZB01C
Status: Started
PPID............. ( 1,303)
BPID................ ( 0,328)
Proto
TCP
TCP
TCP
Faddr
0.0.0.0
0.0.0.0
0.0.0.0
Status
LISTEN
LISTEN
LISTEN
Laddr
0.0.0.0
0.0.0.0
0.0.0.0
Lport
ftp
finger
echo
Fport
*
*
*
SendQ
0
0
0
RecvQ
0
0
0
5. Using the information obtained from the SCF STATUS PROCESS commands,
record the processor numbers for the preferred and alternate NonStop TCP/IP,
TCPSAM, or TCP6SAM processes in the cpunum and altcpunum fields of SCF
ADD DEVICE Command Worksheet, respectively.
6. Add the satellite-connect or direct-connect line-handler process as a device to the
WAN subsystem using the values you recorded in the SCF ADD DEVICE
Command Worksheet.
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name, &
IOPOBJECT $SYSTEM.SYS00.LHOBJ, TYPE (63,5), RSIZE 0, &
LINETF 3, ADAPTER concname, CLIP clipnum, LINE linenum, &
PATH pathnum, CPU cpunum, ALTCPU altcpunum, NEXTSYS sysnum
Note. If you want the satellite-connect or direct-connect line-handler process to be part of
a multi-CPU path, specify the SUPERPATH_ON modifier in the SCF ADD DEVICE
command. You can configure a maximum of 16 paths in a multi-CPU path.
Expand Configuration and Management Manual—523347-008
1 -9
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
Table 1-3. SCF ADD DEVICE Command Worksheet
Parameter
Value/Description
device_name
The name you want to assign to the Expand line-handler process.
name
The name of the profile you created in Task 3: Add the Expand LineHandler Profile(s) on page 1-4.
concname
____________________ (Task 4, Step 2a)
clipnum
____________________ (Task 4, Step 2b)
linenum
____________________ (Task 4, Step 2c)
pathname
____________________ (Task 4, Step 2d)
cpunum
____________________ (Task 4, Step 5)
altcpunum
____________________ (Task 4, Step 5)
sysnum
Specifies the number of the system connected to the other end of the
line. System numbers can be displayed using the SCF INFO
PROCESS $NCP, LINESET command.
Note. The device name is a string of alphanumeric characters. The string is limited to the
pound (#) sign followed by seven characters. The first character must be an alphanumeric
character. For subsystem-specific naming guidelines, see the WAN Subsystem Configuration
and Management Manual.
Expand-Over-IP Line-Handler Process
The Expand-over-IP line-handler process must be associated with a NonStop TCP/IP
process for conventional NonStop TCP/IP, a TCPSAM process for Parallel Library
TCP/IP, or a TCP6SAM process for NonStop TCP/IPv6. Expand uses an Ethernet
SUBNET and a User Datagram Program (UDP) port defined for the NonStop TCP/IP
process.
Configuring NonStop TCP/IP processes is not described in here; you can find
information about this topic in Section 8, Configuring Expand-Over-IP Lines.
To create an Expand-over-IP line-handler process, perform the following step:
1. Add the Expand-over-IP line-handler process as a device to the WAN subsystem.
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,0), RSIZE 0, PATHTF 3, NEXTSYS sysnum, &
ASSOCIATEDEV tcpip_process, DESTIPADDR dipaddr,&
DESTIPPORT dipport, SRCIPADDR sipaddr, &
SRCIPPORT sipport
Expand Configuration and Management Manual—523347-008
1-10
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
If you want to use IPv6 communications, add the device as follows:
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,0), RSIZE 0, PATHTF 2, NEXTSYS sysnum,&
ASSOCIATEDEV tcp6sam_process, IPVER_IPV6,&
V6SRCIPADDR ipv6srcaddress, V6DESTIPADDR ipv6destaddress,&
SRCIPPORT sipport, DESTIPPORT dipport
Note. If you want the Expand-over-IP line-handler process to be part of a multi-CPU path,
specify the SUPERPATH_ON modifier in the SCF ADD DEVICE command. You can configure
a maximum of 16 paths in a multi-CPU path.
Table 1-4. SCF ADD DEVICE Syntax: Expand-Over-IP (page 1 of 2)
Parameter
Description
device_name
The name you want to assign to the Expand line-handler process.
name
The name of the profile you created in Task 3: Add the Expand LineHandler Profile(s).
cpunum
The number of the primary processor.
sysnum
The number of the system connected to the other end of the line.
System numbers can be displayed using the SCF INFO PROCESS
$NCP, LINESET command.
altcpu
The number of the alternate processor.
tcpip_process
The name of the NonStop TCP/IP or Parallel Library TCP/IP
(TCPSAM) process you want to associate with the Expand-over-IP
line-handler process. For NonStop TCP/IP, the NonStop TCP/IP
process must be configured in the same processor pair as the
Expand-over-IP line-handler process. For Parallel Library TCP/IP,
there is no such restriction for the TCPSAM process but there must
be a Parallel Library TCP/IP subsystem monitor process
($ZZTCP.#ZPTMn, where n is the processor number) in the
processors that contain the Expand-over-IP line-handler process
pair.
Expand Configuration and Management Manual—523347-008
1-11
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
Table 1-4. SCF ADD DEVICE Syntax: Expand-Over-IP (page 2 of 2)
Parameter
Description
tcp6sam_process
The name of the NonStop TCP/IPv6 TCP6SAM process you want to
associate with the Expand-over-IP line-handler process. The
TCP6SAM process does not need to be configured in the same
processor pair as the Expand-over-IP line-handler process but there
must be a NonStop TCP/IPv6 subsystem monitor process
($ZZTCP.#ZPTMn, where n is the processor number) in the
processors that contain the Expand-over-IP line-handler process
pair. If you use NonStop TCP/IPv6 in INET (IPv4) mode, it behaves
similarly to Parallel Library TCP/IP and the additional parameters for
IPv6, IPVER_IPV6, V6SRCIPADDR, and V6DESTIPADDR are not
needed. DESTIPADDR is required for INET operations, however.
NonStop TCP/IPv6 has a feature not present in Parallel Library
TCP/IP called logical network partitioning (LNP) that affects
configuration. See Internet Protocol (IP) Networks on page 3-4 for
more information about this feature.
dipaddr
The IP address used by the remote (destination) Expand-over-IP
line-handler process. The address must be specified by number.
dipport
The UDP port number used by the remote (destination) Expandover-IP line-handler process.
sipaddr
The IP address used by the NonStop TCP/IP process specified by
tcpip_process. The address must be specified by number.
sipport
The UDP port number used by this Expand-over-IP line-handler
process. Valid values are in the range 0 through 65536. Do not use
well-known ports in the range 0 through 1023.
ipv6srcaddress
The IP address used by the NonStop TCP/IP process specified by
the tcpipV6_process. The address must be specified by
number.
ipv6destaddress
The IP address used by the NonStop TCP/IP process specified by
the tcpipV6_process. The address must be specified by
number.
Expand-Over-ATM Line-Handler Process
The Expand-over-ATM line-handler process must be associated with an Asynchronous
Transfer Mode (ATM) line. It can use a switched virtual circuit (SVC) or a permanent
virtual circuit (PVC) connection.
Expand-over-ATM lines can also use the ATMSAP connection option through the
SLSA subsystem.
Configuring the ATM subsystem is not described here; you can find information about
this topic in Section 9, Configuring Expand-Over-ATM Lines.
To create an Expand-over-ATM line-handler process, perform the following step:
Expand Configuration and Management Manual—523347-008
1-12
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
1. Add the Expand-over-ATM line-handler process as a device to the WAN
subsystem
Use the following command syntax if the Expand-over-ATM line-handler process
will use a PVC connection:
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,0), RSIZE 0, PATHTF 3, ASSOCIATEDEV atm_line,&
ASSOCIATESUBDEV #IP, CALLTYPE_PVC, PVCNAME pvc-name,&
NEXTSYS sysnum
Use the following command syntax if the Expand-over-ATM line-handler process
will use an SVC connection:
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,0), RSIZE 0, PATHTF 3, ASSOCIATEDEV atm_line,&
ASSOCIATESUBDEV #IP, CALLTYPE_SVC, ATMSEL selector-byte,&
DESTATMADDR (isonsap:%hatm-address), NEXTSYS sysnum
Use the following command syntax for an Expand-over-ATM line-handler process
using an ATMSAP connection through the SLSA subsystem:
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,0), RSIZE 0, PATHTF 3, CALLTYPE_ATMSAP,&
LIFNAME lif-name, NEXTSYS sysnum
Note. If you want the Expand-over-ATM line-handler process to be part of a multi-CPU path,
specify the SUPERPATH_ON modifier in the SCF ADD DEVICE command. You can configure
a maximum of 16 paths in a multi-CPU path.
Table 1-5. SCF ADD DEVICE Syntax: Expand-Over-ATM (page 1 of 2)
Parameter
Description
device_name
The name you want to assign to the Expand line-handler process.
name
The name of the profile you created in Task 3: Add the Expand LineHandler Profile(s).
cpunum
The number of the primary processor.
altcpu
The number of the alternate processor.
atm_line
The device name of the ATM line you want to associate with this
Expand-over-ATM line-handler process.
lif_name
The name of the logical interface by which LAN access is known to
the system. This name can be up to eight characters long, nullterminated, and case-sensitive. This modifier is only applicable to
Expand-over-ATM line-handler processes that use ATMSAP
connections though the SLSA subsystem.
Expand Configuration and Management Manual—523347-008
1-13
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
Table 1-5. SCF ADD DEVICE Syntax: Expand-Over-ATM (page 2 of 2)
Parameter
Description
pvc_name
The name of the permanent virtual circuit (PVC) used by the Expandover-ATM line-handler process. This modifier is only applicable to
Expand-over-ATM line-handler processes that use PVC connections.
selector-byte
A selector byte for the ATM line used by this Expand-over-ATM linehandler process. The selector byte is the last (rightmost) byte of the
ATM address. This modifier is only applicable to Expand-over-ATM
line-handler processes that use SVC connections.
atm-address
The 20-byte ATM address configured for the ATM line used by the
Expand-over-ATM line-handler process at the remote system. The
address must be preceded by the characters ISONSAP:%H and must
be enclosed in parentheses. This modifier is only applicable to
Expand-over-ATM line-handler processes that use SVC connections.
sysnum
The number of the system connected to the other end of the line.
System numbers can be displayed using the SCF INFO PROCESS
$NCP, LINESET command.
Expand-Over-X.25, Expand-Over-SNA, Expand-OverServerNet, and Expand-Over-FOX Line-Handler Processes
Expand-over-X.25, Expand-over-SNA, Expand-over-ServerNet, and Expand-over-FOX
line-handler processes require the services of the following software components:
•
•
•
•
The Expand-over-X.25 line-handler process must be associated with an X25AM
process. It uses a NAM subdevice defined for the X25AM process. You can find
information about this topic in Section 10, Configuring Expand-Over-X.25 Lines.
The Expand-over-SNA line-handler process must be associated with a SNAX/APN
line-handler process. It uses a particular SNAX/APN line and logical unit (LU)
defined for the SNAX/APN line-handler process. You can find more information
about this topic in Section 11, Configuring Expand-Over-SNA Lines.
The Expand-over-ServerNet line-handler process must be associated with the
ServerNet monitor process ($ZZSCL), a component of the ServerNet cluster
subsystem. You can find more information about this topic in Section 12,
Configuring Expand-Over-ServerNet Lines.
The Expand-over-FOX line-handler process must be associated with the FOX
monitor process ($ZZFOX), a component of the ServerNet/FX adapter subsystem.
You can find information about this topic in Section 13, Configuring Expand-OverFOX Lines.
To create an Expand-over-X.25, Expand-over-SNA, Expand-over-ServerNet, or
Expand-over-FOX line-handler process, perform the following step:
Expand Configuration and Management Manual—523347-008
1-14
Creating a Single-Line Expand Line-Handler
Process
Configuration Quick Start
1. Add the Expand-over-SNA, Expand-over-X.25, Expand-over-ServerNet, or
Expand-over-FOX line-handler process as a device to the WAN subsystem.
-> ADD DEVICE $ZZWAN.#device_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,subtype), RSIZE 0, PATHTF 3, ASSOCIATEDEV process, &
ASSOCIATESUBDEV #subdevice, NEXTSYS sysnum
Note. If you want the Expand-over-X.25 or Expand-over-SNA line-handler process to be part
of a multi-CPU path, specify the SUPERPATH_ON modifier in the SCF ADD DEVICE
command. You can configure a maximum of 16 paths in a multi-CPU path. Expand-overServerNet and Expand-over-FOX line-handler processes cannot participate as a member of a
multi-CPU path (superpath).
Table 1-6. SCF ADD DEVICE Syntax: Expand-Over-X.25, Expand-Over-SNA,
Expand-Over-ServerNet, and Expand-Over-FOX
Parameter
Description
device_name
The name you want to assign to the Expand line-handler process.
name
The name of the profile you created in Task 3: Add the Expand LineHandler Profile(s).
cpunum
The primary processor number.
altcpu
The alternate processor number.
subtype
The subtype. The subtype is 0 for Expand-over-X.25 and Expand-overSNA line-handler processes; it is 3 for Expand-over-FOX and 4 for
Expand-over-ServerNet line-handler processes.
process
•
•
subdevice
•
•
•
•
•
•
sysnum
For Expand-over-X.25: the name of an X25AM line-handler
process.
For Expand-over-SNA: the name of a SNAX/APN line-handler
process.
For Expand-over-ServerNet: must be $ZZSCL.
For Expand-over-FOX: must be $ZZFOX.
For Expand-over-X.25: the name of an X25AM subdevice defined
for the X25AM process specified by process.
For Expand-over-SNA: the name of a local LU (with the NAM
protocol) defined for the SNAX/APN process specified by
process.
For Expand-over-ServerNet: this modifier is not used.
For Expand-over-FOX: this modifier is not used.
The number of the system connected to the other end of the line.
System numbers can be displayed using the SCF INFO PROCESS
$NCP, LINESET command.
Expand Configuration and Management Manual—523347-008
1-15
Creating a Multi-Line Path
Configuration Quick Start
Creating a Multi-Line Path
This section describes how to configure a multi-line path.
1. Create the path-logical device.
-> ADD DEVICE $ZZWAN.#path_name, PROFILE name,&
IOPOBJECT $SYSTEM.SYS00.LHOBJ, CPU cpunum, ALTCPU altcpu,&
TYPE (63,1), RSIZE 0, PATHTF 3, NEXTSYS sysnum
Note. If you want the multi-line path to be part of a multi-CPU path, specify the
SUPERPATH_ON modifier in the SCF ADD DEVICE command. You can configure a maximum
of 16 paths in a multi-CPU path.
Table 1-7. ADD DEVICE Syntax: Path-Logical Device
Parameter
Description
path_name
The name you want to assign to the path-logical device.
name
The name of the profile you created in Task 2, Step 2a.
cpunum
The number of the primary processor.
altcpu
The number of the alternate processor.
sysnum
The number of the system connected to the other end of the multi-line
path. System numbers can be displayed using the SCF INFO
PROCESS $NCP, LINESET command.
2. To create lines in the multi-line path (called line-logical devices), use the SCF ADD
DEVICE command syntax shown for configuring single-line Expand line-handler
processes (see Creating a Single-Line Expand Line-Handler Process on page 1-6),
but with the following exceptions:
•
Use the TYPE modifier values as shown in Table 1-8.
Table 1-8. Subtypes for Line-Logical Devices
Type of Line-Logical
Device
TYPE Modifier Value
Profile
Direct-connect
(63,6)
PEXQMSWN
Satellite-connect
(63,6)
PEXQMSAT
Expand-over-X.25
(63,2)
PEXQMNAM
Expand-over-SNA
(63,2)
PEXQMNAM
Expand-over-IP
(63,2)
PEXQMIP
Expand-over-ATM
(63,2)
PEXQMATM
•
Omit the NEXTSYS modifier; it was specified when you configured the pathlogical device.
Expand Configuration and Management Manual—523347-008
1-16
Configuration Quick Start
•
Where to Find More Information About This Task
Include the MULTI modifier as follows:
MULTI $path_name
where path_name is the name of the path-logical device you created in
Step 1.
The following rules apply when creating line-logical devices:
•
•
You can configure a maximum of eight lines in a multi-line path.
The path-logical device and all of the line-logical devices with which it is associated
must be configured in the same processor pair.
The following is an example of an SCF ADD DEVICE command that adds a line-logical
device for an Expand-over SNA line:
-> ADD DEVICE $ZZWAN.#LINE2, PROFILE MLHSNA,&
IOPOBJECT $SYSTEM.SYS01.LHOBJ, CPU 0, ALTCPU 1,&
TYPE (63,2), RSIZE 0, PATHTF 3, ASSOCIATEDEV $SNA1,&
ASSOCIATESUBDEV #SNAM, MULTI $PATH
Where to Find More Information About This Task
Section 7, Configuring Direct-Connect and Satellite-Connect Lines
Section 8, Configuring Expand-Over-IP Lines
Section 9, Configuring Expand-Over-ATM Lines
Section 10, Configuring Expand-Over-X.25 Lines
Section 11, Configuring Expand-Over-SNA Lines
Section 12, Configuring Expand-Over-ServerNet Lines
Section 13, Configuring Expand-Over-FOX Lines
Section 14, Configuring Multi-Line Paths
Task 5: Start the Expand Line-Handler Process
Start the single-line Expand line-handler process or path-logical device. When you use
this command to start a path-logical device, the line-logical devices associated with the
path are also started.
-> START DEVICE $ZZWAN.#device_name
where device_name is the device name of the Expand line-handler process or pathlogical device.
Expand Configuration and Management Manual—523347-008
1-17
Configuration Quick Start
Establishing a Connection
Establishing a Connection
To establish a connection between two NonStop S-series servers, repeat the tasks
described in this section to create an Expand line-handler process at the neighbor
system.
If the neighbor system is a NonStop K-series server (or other type of NonStop system),
you must use the system generation program or the COUP interface to the Dynamic
System Configuration (DSC) utility to create an Expand line-handler process at the
neighbor system.
Refer to the System Generation Manual for Expand or the Dynamic System
Configuration (DSC) Manual in the D-series documentation for more information.
Once you have configured and started Expand line-handler processes at both the local
and destination systems, you can start the Expand line (or lines).
Starting an Expand Path
To start a single-line path, use the following command:
-> START LINE $device_name
where device_name is the name of a single-line Expand line-handler process.
Starting Lines in a Multi-Line Path
To start all the lines in a multi-line path, use the following command:
-> START PATH $path_name
where path_name is the name of a the path-logical device.
To start specific lines in a multi-line path, use the following command:
-> START LINE $line_name
where line_name is the name of a logical device.
Expand Configuration and Management Manual—523347-008
1-18
2
Expand Overview
The Expand subsystem enables you to connect as many as 255 geographically
dispersed NonStop servers to create a network with the reliability, capacity to preserve
data integrity, and potential for expansion of a single NonStop server.
This section provides a high-level overview of the Expand subsystem by describing the
following major features and capabilities:
•
•
•
•
•
•
•
•
Network Transparency on page 2-1
Multiple Communications Environments on page 2-5
Distributed Control on page 2-7
Automatic Message Routing on page 2-7
Fault-Tolerant Operation on page 2-8
Network Management on page 2-9
Online Expansion and Reconfiguration on page 2-10
Network Security on page 2-11
Network Transparency
To a user or an application, every server in an Expand network appears to be part of a
single server. When accessing a file or other resource on a server in an Expand
network, a user or an application does not need to know which route to take to reach
the destination or whether the destination is local or remote.
Interactive Access
When accessing a remote file or another resource interactively on an Expand network,
you use the same command or utility that you would normally use to perform the task
on your local server. For example, if you wanted to use the File Utility Program (FUP)
DUP command to copy a file named file1 in volume $myfiles, subvolume
subvol1, to a file named file2 in volume $yrfiles, subvolume subvol2, on your
local server, you would use the following command:
>fup dup $myfiles.subvol1.file1,$yrfiles.subvol2.file2
If you wanted to copy the same file to a remote server called \remote, you would use
the following command:
>fup dup $myfiles.subvol1.file1,\remote.$yrfiles.subvol2.file2
In most cases, the only difference between accessing remote and accessing local
resources is that you must specify the name of the remote server when accessing a
remote resource.
Expand Configuration and Management Manual—523347-008
2 -1
Programmatic Access
Expand Overview
Programmatic Access
When accessing a file or another resource programmatically across an Expand
network, you use the same procedure calls you would use when writing a local
application. With a few exceptions, applications that were written to run in a local
environment can be used virtually unchanged in a network environment.
Expand Subsystem and the NonStop Kernel
The Expand subsystem is an extension of the HP NonStop Kernel operating system.
You can use the same methods for remote and local file access because the NonStop
Kernel and the Expand subsystem provide a uniform, message-based interface
between applications and operating system processes on different servers. The
message-based interface has two parts: the file system and the message system.
The size of the message sent between Expand processes is determined by many
factors.
For G06.06 and D40 RVUs, the upper size limit of 32K bytes has been increased to
60K bytes, with the following limitations.
•
•
•
•
The 60K byte messages may only be sent between nodes which support 60K byte
messaging. The Expand line handlers at both the source and target nodes (CPUs)
must support the same size setting, that is, they must be at the same software
version (intermediate node versions do not matter).
Within any one node, Expand line handlers must all be at the same version.
All nodes supporting the 60K byte messages are required to use L4 Extended
packets: L4EXTPACKETS ON.
The NonStop Kernel file system limit of 56K bytes has not been increased.
Expand Configuration and Management Manual—523347-008
2 -2
Expand Subsystem and the NonStop Kernel
Expand Overview
Single-Server Process Communications
Figure 2-1 illustrates how a process on one processor uses the file system to make an
inquiry of a process residing on another processor in the same server. The message
system relays the request through the ServerNet system area network (ServerNet
SAN).
Figure 2-1. Single-Server Process Communications
Processor 0
Processor 1
User
Process
Message
System
Message
System
Disk
Process
Y-Fabric
X-Fabric
ServerNet
Adapter
Disks
ServerNet
Adapter
CDT 037.CDD
Expand Configuration and Management Manual—523347-008
2 -3
Expand Subsystem and the NonStop Kernel
Expand Overview
Multi-Node Process Communications
Figure 2-2 illustrates the same file-system request as Figure 2-1, except that the disk
process resides on another node in the network rather than on another processor in
the same server.
Figure 2-2. Multi-Node Process Communications
Node \B
Node \A
Processor 0
Processor 0
Processor 1
Message
System
User
Process
Message
System
Expand
Line-Handler
Process
Message
System
Processor 1
Message
System
Expand
Line-Handler
Process
Disk
Process
Y-Fabric
Y-Fabric
X-Fabric
X-Fabric
LAN
Adapter
LAN
Adapter
LAN
Adapter
LAN
Adapter
SWAN
SWAN
Expand Link
SWAN
SWAN
CDT 038.CDD
Multi-node process communications is the same as single-server process
communications, with the following exceptions:
•
•
The Expand subsystem redirects the file-system request to a hardware
communications device.
A communications line rather than the ServerNet SAN carries the message to the
remote process.
Expand Configuration and Management Manual—523347-008
2 -4
Multiple Communications Environments
Expand Overview
Note. Incoming and outgoing messages usually bypass the Expand line-handler process and
are handled directly by the ServerNet fabrics and the ServerNet/Fiber eXtension
(ServerNet/FX) adapters when servers are connected by fiber-optic cables in a FOX ring. FOX
rings are explained in Fiber-Optic Cables on page 2-6.
Multiple Communications Environments
Nodes in an Expand network can be connected using a variety of data communications
technologies and protocols. A single network can consist of any combination of these
different data communications methods.
Nodes in an Expand network can be connected by
•
•
•
•
•
•
•
Full-duplex leased lines or satellite connections using the High-Level Data Link
Control (HDLC) protocol
X.25 virtual-circuit connections to a packet-switched data network (PSDN)
Connections to IBM Systems Network Architecture (SNA) networks
Local area network (LAN) or wide area network (WAN) connections to networks
that use the Internet Protocol (IP)
Local area network (LAN) or wide area network (WAN) connections to
Asynchronous Transfer Mode (ATM) networks
Multi-mode fiber-optic cables (FOX rings)
Single-mode fiber-optic cables (ServerNet clusters)
Leased and Satellite Connections
You can connect Expand nodes with leased or satellite lines using either the HDLC
Normal protocol or the HDLC Extended Mode protocol.
•
•
The HDLC Normal protocol is provided for use with conventional voice-grade
leased-line and switched-line facilities.
The HDLC Extended Mode protocol is a satellite-efficient version of HDLC and is
provided for use with satellite connections.
Note. There is no automatic dialing function within the Expand subsystem for dial-up lines.
Expand Configuration and Management Manual—523347-008
2 -5
X.25 Packet-Switched Networks
Expand Overview
X.25 Packet-Switched Networks
X.25 is a standard for private and public networks that use packet-switching
technology. Some examples of packet-switched networks include SPRINTNET,
TELENET, and TYMNET in the United States; DATAPAC in Canada; DATEX in
Germany; TRANSPAC in France; and PSS in Great Britain.
Expand-over-X.25 connections are provided with the HP X.25 Access Method
(X25AM) product. The Expand subsystem uses the NETNAM protocol to communicate
with an X25AM line-handler process.
Systems Network Architecture (SNA) Networks
SNA was developed by IBM for connecting IBM systems and networks. Expand-overSNA connections are provided with the HP SNAX/Advanced Peer Networking
(SNAX/APN) product. The Expand subsystem uses the NETNAM protocol to
communicate with the SNAX/APN line-handler process.
Internet Protocol (IP) Networks
An IP network adheres to the Internet Protocol—a computer-industry standard
protocol. An ever-increasing number of public and private networks are based on IP,
including the Internet itself. Expand-over-IP connections are provided by the NonStop
TCP/IP products.
Asynchronous Transfer Mode (ATM) Networks
ATM is a cell-switching and multiplexing technology that combines the benefits of
circuit switching (constant transmission delay and guaranteed capacity) with those of
packet switching (flexibility and efficiency for intermittent traffic). Expand-over-ATM
connections are provided with the ATM subsystem.
Fiber-Optic Cables
A FOX ring consists of two separate, bidirectional, fiber-optic rings and can connect as
many as 14 servers in a limited geographical area. The ServerNet/Fiber eXtension
(ServerNet/FX) adapters allow you to connect a NonStop S-series server to an existing
FOX ring. The existing FOX ring can consist of NonStop K-series and Cyclone
systems.
Note. FOX is an abbreviation for Fiber Optic eXtension. The term FOX ring is used in this
manual to refer to networks that are connected using FOXII, TorusNet, or ServerNet/FX
hardware.
Expand Configuration and Management Manual—523347-008
2 -6
ServerNet Clusters
Expand Overview
ServerNet Clusters
ServerNet Clusters use Expand to provide a high-speed interconnect between servers
over a limited geographic range. Three network topologies are supported: the star,
split-star, and tri-star topologies. The star topology supports up to eight nodes. The
split-star topology supports up to 16 nodes. The tri-star topology supports up to 24
nodes
The 16-node configuration is split between two NonStop cluster switches per external
fabric in what is known as a split-star topology and the 24-node configuration is split
between three cluster switches per external fabric in what is known as a tri-star
topology. Using single-mode fiber-optic cables to link the two centers of the split-star
and the three centers of the tri-star allows a greater distance (up to 1 kilometer)
between the cluster switches and their connected nodes.
For detailed topology information, see Section 4, Planning for ServerNet Clusters.
A NonStop S-series server cannot participate in more than one ServerNet cluster.
Distributed Control
The control function of the Expand subsystem is distributed throughout the network.
Unlike a hierarchical network, in which a central computer, or host, controls the
communications environment, nodes in an Expand network communicate with each
other as peers. Distributed networks have the following additional advantages:
•
•
•
Distributed applications. Applications can be distributed so that multiple nodes
share the processing load.
Flexible network topologies. The network topology can be designed without regard
to host or controlling processors.
Network reliability. Failure of one node does not necessarily affect the operation of
other nodes in the network.
Automatic Message Routing
The Expand subsystem’s routing facilities ensure that a message sent from any node
in the network will arrive at its destination as long as there is at least one active
communications path available. The Expand subsystem’s routing capabilities also
include the following:
•
•
•
Passthrough Routing
Best-Path Routing
Priority Routing
Refer to Time Factors and Pathchange Messages on page 18-24 for information on
adjusting settings so that routing is optimal.
Expand Configuration and Management Manual—523347-008
2 -7
Passthrough Routing
Expand Overview
Passthrough Routing
The Expand subsystem uses a sophisticated routing scheme that permits intermediate
nodes to route, or pass through, data packets to the destination node. This scheme
reduces the number of lines required between nodes because nodes do not have to be
directly connected in order to exchange data.
Best-Path Routing
When a message is sent over an Expand network, the Expand subsystem determines
the best-path route to the destination node by calculating time factors (TFs) and the
number of intermediate nodes (or hops) to the destination node. A TF is calculated for
a line, path, or route. The best-path route is the route with the lowest TF and hop count
(HC).
The Expand subsystem dynamically revises its best-path route determination if a node
or path status changes when nodes or paths become operational or nonoperational.
TF calculation and best-path route selection are discussed in Section 18, Subsystem
Description.
Priority Routing
You can assign different priorities to messages sent over an Expand network. Priority
routing allows an important message to reach its destination even when the network is
congested.
Fault-Tolerant Operation
Using careful configuration and network-topology design, you can configure an Expand
network to be continuously available.
You can configure as many as eight lines between the same two nodes using the
Expand subsystem’s multi-line path feature. The Expand subsystem can
simultaneously transmit data over all of the lines, thus increasing overall bandwidth,
and will automatically reroute data over remaining lines if one or more lines fail.
You can configure as many as 16 paths between the same two nodes using the
Expand multi-CPU feature. The Expand multi-CPU feature enables you to spread the
communications load over multiple processors by connecting multiple Expand
line-handler processes on separate processors at one node to Expand line-handler
processes on separate processors on another node. The Expand subsystem transmits
data between neighbor nodes over all of the paths in a multi-CPU path, and will
automatically reroute data over remaining paths if one or more paths fail. The Expand
subsystem also uses a rebalancing algorithm to ensure that the average
communications load of all the paths in a multi-CPU path is close to equal.
You can also configure lines to be controlled by different communications hardware
devices to ensure that a single hardware failure will not disable a connection between
two servers.
Expand Configuration and Management Manual—523347-008
2 -8
Network Management
Expand Overview
Network Management
Network management involves several tasks, including
•
•
•
Monitoring, modifying, and controlling the network
Resolving network problems
Analyzing and tuning network performance
The Expand subsystem supports a variety of network-management utilities and tools to
help you perform these tasks:
•
•
•
•
•
•
Subsystem Control Facility (SCF)
Event Management Service (EMS)
Availability Statistics and Performance (ASAP)
Measure
Compaq TSM Package
OSM Interface
Note. Refer to Part III of this manual, Subsystem Control Facility (SCF), for information on
managing Expand using SCF.
Subsystem Control Facility (SCF)
SCF is a Distributed Systems Management (DSM) interface that can be used
interactively to control, configure, and monitor the Expand subsystem. The SCF
interfaces to the Expand and wide area network (WAN) subsystems are used to
configure and manage the Expand subsystem. The SCF interface to the Expand
subsystem is described in Section 15, Subsystem Control Facility (SCF) Commands.
The SCF interface to the WAN subsystem is described in the WAN Subsystem
Configuration and Management Manual.
Event Management Service (EMS)
EMS is a DSM interface that provides event collection, logging, and distribution
facilities. Both the Expand and ServerNet adapter subsystems report events to EMS.
Event messages are described in the Operator Messages Manual.
Availability Statistics and Performance (ASAP)
The Availability Statistics and Performance (ASAP) monitoring tool provides graphical
and tabular displays of system and network object performance, object state, and
entity threshold information. The Availability Statistics and Performance Extension
(ASAPX) product integrates and extends ASAP monitoring capabilities to single and
multi-node application environments. For more information about ASAP, refer to the
following manuals: ASAP Client Manual, ASAP Server Manual, ASAP Extension
Manual, and ASAP Migration Guide for NSX and OMF Users.
Expand Configuration and Management Manual—523347-008
2 -9
Measure
Expand Overview
Measure
Measure is a tool for monitoring the performance of NonStop servers. In an Expand
network, Measure can help determine node-to-node activity and processor and line
use by Expand line-handler processes. Measure is described in the Measure User’s
Guide.
Compaq TSM Package
TSM is a client/server application that provides troubleshooting, maintenance, and
service tools. TSM consists of software components that run on the NonStop S-series
server and on a PC-compatible workstation. The TSM software on the workstation
features an easy-to-use graphical user interface (GUI) that contains extensive online
help.
TSM is described in the OSM Migration Guide and the TSM Online User Guide.
OSM Interface
For G06.21, the HP Open System Management (OSM) product replaces TSM as the
system management tool of choice for NonStop S-series systems. While TSM is still
supported, OSM offers a browser-based interface that improves scalability and
performance as well as improving upon other limitations of TSM. OSM is required for
support of new functionality released at G06.21 and beyond.
For more information about OSM, see the OSM User’s Guide and the OSM Migration
Guide.
Online Expansion and Reconfiguration
You can add a new node or new lines to a network or move an existing node to a
different location without disrupting network activity.
You can make changes to your Expand configuration online using the Subsystem
Control Facility (SCF) interfaces to the Expand and WAN subsystems. Table 2-1 shows
the online expansion and reconfiguration tasks that can be performed with these
interfaces.
Table 2-1. Online Reconfiguration Tasks (page 1 of 2)
Task
SCF for
Expand
SCF for
WAN
Adding the network control process
No
Yes
Adding an Expand line-handler process
No
Yes
Reconfiguring the network control process
Yes1
Yes2
Reconfiguring an Expand line-handler process
Yes1
Yes2
Expand Configuration and Management Manual—523347-008
2- 10
Network Security
Expand Overview
Table 2-1. Online Reconfiguration Tasks (page 2 of 2)
Task
SCF for
Expand
SCF for
WAN
Deleting the network control process
No
Yes
Deleting an Expand line-handler process
No
Yes
1. Changes made with SCF for the Expand subsystem are temporary; they do not remain across system loads.
2. Changes made with SCF for the WAN subsystem are permanent; they do remain across system loads.
The SCF interface to the Expand subsystem is described in Section 15, Subsystem
Control Facility (SCF) Commands. The SCF interface to the WAN subsystem is
described in the WAN Subsystem Configuration and Management Manual.
Network Security
The Expand subsystem provides security features to control access to remote servers
and files.
Remote Passwords
To access a remote server, you must have a username and user ID on the remote
server that is identical to those on the local server. You use the REMOTEPASSWORD
command to set up two remote passwords for the local username and user ID: one to
establish a remote password for the local server, and one to establish a remote
password for the remote server. You again use the REMOTEPASSWORD command to
set up remote passwords for the remote username and user ID.
Note. Setting up remote passwords is explained in the Guardian User’s Guide.
Before you can access a file on a remote server, you must have the proper security as
well as remote passwords for both the local and remote servers. Each file has
associated security attributes that can be changed with the FUP SECURE command.
Enhanced Security Techniques
The Safeguard security system enhances the security provided by both the Expand
subsystem and the NonStop Kernel operating system. Safeguard enables you to set
password expiration dates, create access control lists, and audit file access.
For an even greater level of security, data encryption devices are available from the HP
Atalla subsidiary.
Expand Configuration and Management Manual—523347-008
2- 11
Expand Overview
Enhanced Security Techniques
Expand Configuration and Management Manual—523347-008
2- 12
3
Planning a Network Design
This section describes the network design decisions you must make before installing
and configuring a new Expand network or when modifying an existing Expand network.
Topics described in this section include
•
•
•
•
•
Selecting Line Protocols on page 3-1
Defining Paths Between Systems on page 3-7
Selecting Special Features on page 3-12
Designing the Network Topology on page 3-13
Creating a Network Diagram on page 3-16
Note. This section is intended to help you make some basic design decisions; it is not meant
to be a comprehensive network design guide. You should consult your HP representative for
more detailed design information.
Selecting Line Protocols
The Expand subsystem supports a variety of different protocols and communications
methods to enable you to connect systems in local area network (LAN) or wide area
network (WAN) topologies. This subsection discusses the advantages and
disadvantages of each of the protocols and communications methods supported by the
Expand subsystem.
Dedicated Lines
The direct-connect line-handler process implements the High-level Data Link (HDLC)
protocol and operates with conventional voice-grade leased-line and switched-line
facilities, private facilities, and fractional Transmission Group 1 (T1) facilities.
The major benefits of dedicated lines are
•
•
Performance. Dedicated lines can be permanently allocated by the telephone
network or carrier and can be conditioned to support fast, reliable data
communications.
Fault-tolerance. You can use the Expand multi-line path feature to enhance the
reliability of dedicated lines. Using this feature, you can configure up to eight
parallel lines between nodes. You should avoid using channels on the same
multiplexer for lines in a multi-line path between two nodes.
The major disadvantage of dedicated lines is inflexibility. When a dedicated line is
leased, it can only be altered by prior arrangement with the telephone company.
Expand Configuration and Management Manual—523347-008
3 -1
Planning a Network Design
Satellite Connections
Satellite Connections
The satellite-connect line-handler process implements the satellite-efficient version of
the HDLC protocol, HDLC Extended Mode. HDLC Extended Mode allows a maximum
window size of 61 frames (the maximum window size is the number of outstanding
frames that can be sent before an acknowledgment is required) and implements the
selective-reject feature. Selective reject causes only frames that arrive in error to be
retransmitted.
The major benefits of satellite connections are
•
•
Price-to-performance ratio. Satellite channels can add a large amount of
transmission capacity, significantly reducing the cost of long-distance
communications.
Fault-tolerance. You can use the multi-line path feature to enhance the reliability of
satellite connections. Using this feature, you can configure up to eight parallel lines
between nodes.
The major disadvantage of satellite connections is potentially long propagation delays
(approximately 240 milliseconds) when sending data to the satellite and then to the
destination node. The reliability of satellite connections can also be adversely affected
by weather and other atmospheric conditions.
Note. You can configure terrestrial lines to use satellite-efficient HDLC Extended Mode. This
type of configuration can enhance the effective capability of terrestrial lines that carry small
messages at high speeds.
X.25 Connections
X.25 is a standard for networks that use packet-switching technology. These networks
include SPRINTNET and TYMNET in the United States; DATAPAC in Canada; DATEXP in Germany; TRANSPAC in France; and PSS in Great Britain.
Expand-over-X.25 connections are provided with the HP X.25 Access Method
(X25AM) subsystem. X25AM supports line speeds of up to 256,000 bps, depending on
the X.25 network used, although speeds above 56,000 bps are not always available.
The major benefits of using X.25 are
•
•
Low cost. The cost of X.25 connections may be less than dedicated lines,
depending on traffic volume. Cost may be further reduced if multiple applications
share the same X.25 link. The Expand subsystem’s implementation of X.25 also
has an additional cost-savings benefit: connections can be automatically
disconnected when not in use and then automatically reconnected when traffic
appears.
Flexibility. Virtually any point in the world can be reached by a packet-switched
data network (PSDN). A PSDN can easily accommodate changing
communications requirements and network expansion.
Expand Configuration and Management Manual—523347-008
3 -2
Planning a Network Design
•
•
Systems Network Architecture (SNA) Connections
Low capital cost/high connectivity. X.25 provides a way to connect a large number
of systems through a single line between a NonStop server and an X.25 network.
This feature can lower communications capital costs by reducing the number of
modems and controller ports that must be purchased. For example, a fully
connected network of 4 servers requires 6 links, 12 modems, and 12 hardware
ports. An X.25 network of 4 servers requires only 4 links, 4 modems, and 4
hardware ports.
Fault-tolerance. Reliability is inherent in the structure of an X.25 network. There
are usually several redundant connections between switching systems in an X.25
network; thus, if one transmission link fails, communications can be rerouted. In
addition, you can use the multi-line path feature to enhance the reliability of X.25
connections. Using this feature, you can configure up to eight parallel lines
between nodes.
The disadvantages of X.25 connections include variable line quality, low speeds, and
long call-setup times. Response time requirements can also rule out the use of X.25
connections because of the amount of time involved in connection-setup and
switching.
Note. Accurately estimating workloads is essential to predicting cost and performance of X.25
links in Expand networks.
Systems Network Architecture (SNA) Connections
Expand-over-SNA connections are provided with the HP SNAX/Advanced Peer
Networking (SNAX/APN) subsystem. The SNAX/APN subsystem can be used to
connect Expand line-handler processes across an SNA network. When SNAX/APN is
used, the Expand line-handler process is configured to communicate with a
SNAX/APN line-handler process that manages the line.
The major benefits of SNA are
•
•
Cost-effectiveness. Expand-over-SNA allows an existing SNA network to be used
to connect NonStop servers. No new lines or equipment need to be set up if
SNAX/APN is already being used to connect the NonStop server to an SNA
network.
Fault-tolerance. You can use the Expand multi-line path feature to enhance the
reliability of SNA connections. Using this feature, you can configure up to eight
parallel lines between nodes.
The major disadvantage of SNA connections is the impact of existing SNA traffic on
line capacities. Accurately estimating workloads is essential to predicting cost and
performance of SNA links in an Expand network.
Expand Configuration and Management Manual—523347-008
3 -3
Planning a Network Design
Internet Protocol (IP) Networks
Internet Protocol (IP) Networks
The IP suite is an important industry standard. Expand-over-IP allows NonStop
systems to be interconnected via inexpensive IP-based routers, making a separate
Expand network unnecessary.
Expand-over-IP uses a NonStop TCP/IP process to implement the TCP/IP protocol
stack. The Expand-over-IP line-handler process communicates with the NonStop
TCP/IP process through the shared memory of the QIO subsystem.
The major benefits of Expand-over-IP connections are
•
•
•
•
Cost-effectiveness. Expand-over-IP allows you to route Expand paths over
industry-standard IP routers. IP-based networks allow many applications to share
high-speed links.
Flexibility. No modifications need to be made to Expand applications to allow them
to run over IP networks. A NonStop server that can access an IP network can be
part of the Expand network.
Fault-tolerance. You can use the multi-line path feature to enhance the reliability of
Expand-over-IP connections. Using this feature, you can configure up to eight
parallel lines between nodes.
Passthrough capability. Packets sent over an IP network path can be forwarded to
another Expand line-handler process, which can be of a different line type and in a
different processor.
Note. On NonStop K-series servers, Expand-over-IP line-handler processes are only
supported on D40 and later systems; however, data received by an Expand-over-IP
line-handler process can be forwarded to a different type of Expand line-handler process on a
non-D40 system. In addition, data received by an Expand line-handler process on a non-D40
system can be forwarded to an Expand-over-IP line-handler process.
As of G06.20, NonStop TCP/IPv6 is available for Expand to use. In addition to
providing the use of IP version 6 communications, this product includes all the Parallel
Library TCP/IP (TCP/IP/PL) functionality made available in G06.08.
You can still choose to run Parallel Library TCP/IP, but you cannot run Parallel Library
TCP/IP and NonStop TCP/IPv6 at the same time. You can run NonStop TCP/IP and
NonStop TCP/IPv6 at the same time, however.
NonStop TCP/IPv6 has three operating mode: INET, INET6, and DUAL. In the INET
mode, only IP version 4 communications are supported and the product is similar to
the Parallel Library TCP/IP product with the addition of some new features. In DUAL
mode, both IPv4 and IPv6 communications are supported. In INET6 mode, only IPv6
communications are supported.
One of the differences between the conventional NonStop TCP/IP subsystem and both
Parallel Library TCP/IP and NonStop TCP/IPv6 for Expand is that there are no
matching-processor configuration requirements for the TCPSAM and TCP6SAM
processes and the Expand line-handler processes. Another difference is that when you
Expand Configuration and Management Manual—523347-008
3 -4
Planning a Network Design
Asynchronous Transfer Mode (ATM) Networks
select a TCPSAM or TCP6SAM process with which to associate your Expand process,
those processes provide access to all the configured TCP/IP SUBNET objects and
their IP addresses.
NonStop TCP/IPv6, however, introduces a feature called logical network partitioning
(LNP), that, when enabled, restricts to which SUBNET objects and IP addresses the
TCP6SAM process has access, much like the conventional NonStop TCP/IP process.
When you are planning your Expand-over-IP environment, you may use LNP to control
over which network interfaces (IP addresses) the Expand line-handler processes run.
See Step 1 (C): Select a Process and SUBNET for NonStop TCP/IPv6 Use on
page 8-13 for examples of working with logical network partitioning.
To determine which TCP/IP subsystem is running on your system, use the SCF
LISTDEV TCPIP command. The text after the last period (.) in the Program field on the
far right of the display is either TCPIP, which identifies the process as a conventional
NonStop TCP/IP process, TCPSAM, which identifies the process as a Parallel Library
TCP/IP process, or TCP6SAM, which identifies the process as a NonStop TCP/IPv6
process. NonStop TCP/IP can coexist on the system with either Parallel Library TCP/IP
or NonStop TCP/IPv6 but Parallel Library TCP/IP and NonStop TCP/IPv6 cannot
coexist with each other.
For more information about LNP and about NonStop TCP/IPv6, see the TCP/IPv6
Configuration and Management Manual and the TCP/IPv6 Migration Manual. For more
information about NonStop TCP/IP, see the TCP/IP Configuration and Management
Manual. For more information about Parallel Library TCP/IP, see the TCP/IP (Parallel
Library) Configuration and Management Manual.
Asynchronous Transfer Mode (ATM) Networks
Asynchronous Transfer Mode (ATM) technology is based on the efforts of the
International Telecommunication Union Telecommunication Standardization Sector
(ITU-T) Study Group XVIII to develop Broadband Integrated Services Digital Network
(BISDN) for the high-speed transfer of voice, video, and data through public networks.
Note. The ITU-T carries out the functions of the former Consultative Committee for
International Telegraph and Telephone (CCITT).
ATM is a cell-switching and multiplexing technology that combines the benefits of
circuit switching (constant transmission delay and guaranteed capacity) with those of
packet switching (flexibility and intermittent traffic). ATM is a connection-oriented
environment.
The Expand-over-ATM line-handler process uses the HP ATM subsystem to implement
Expand-over-ATM connectivity. The Expand-over-ATM line-handler process
communicates with the ATM subsystem through the shared memory of the QIO
subsystem.
Expand Configuration and Management Manual—523347-008
3 -5
Planning a Network Design
ServerNet Connections
The major benefits of Expand-over-ATM connections are
•
•
•
•
Flexibility. No modifications need to be made to Expand applications to allow them
to run over ATM networks. A NonStop server that can access an ATM network can
be part of the Expand network.
Fault-tolerance. You can use the multi-line path feature to enhance the reliability of
Expand-over-ATM connections. Using this feature, you can configure up to eight
parallel lines between nodes.
High-speed connectivity and increased throughput. The ATM subsystem supports
the ATM User-Network Interface (UNI) Specification Version 3.0 over a 155 Mbps
SONET STS-3c connection.
Passthrough capability. Packets sent over an ATM network path can be forwarded
to another Expand line-handler process, which can be a different line type and in a
different processor.
ServerNet Connections
The Expand-over-ServerNet line-handler process provides connectivity to a ServerNet
cluster, which uses this process to provide a very high speed proprietary interconnect
between systems over a limited geographic range.
The Expand-over-ServerNet line-handler process accesses the network access
method (NAM) interface of the ServerNet cluster monitor process, $ZZSCL. The major
benefits of connections using ServerNet clusters are
•
•
•
•
Faster transmission speed and larger packet sizes. The ServerNet II cluster switch
uses router-2 technology, which provides crossbar wormhole routing of ServerNet
packets between 12 input ports and 12 output ports. (The ServerNet I cluster
switch is not supported.)
Fault-tolerance. The ServerNet cluster uses one ServerNet II cluster switch for the
X fabric and one ServerNet II cluster switch for the Y fabric. These two cluster
switches can support up to eight nodes. For fault-tolerance, each node connects to
both cluster switches.
Connectivity. ServerNet clusters can coexist with FOX rings, ATM or IP networks,
and other WAN and LAN products.
Manageability. The ServerNet cluster’s quick-disconnect capability makes it easier
to implement planned outages.
An Expand-over-ServerNet line-handler process can be configured as a single line
only; Expand-over-ServerNet lines cannot participate as a member of a multi-CPU path
(superpath).
Refer to Time Factors and Pathchange Messages on page 18-24 for information on
adjusting settings so that routing is optimal.
Expand Configuration and Management Manual—523347-008
3 -6
Planning a Network Design
FOX Connections
FOX Connections
The Expand-over-FOX line-handler process provides connectivity in a limited
geographical area by accessing the network access method (NAM) interface of the
FOX monitor process, $ZZFOX. The major benefits of FOX connections are
•
•
•
•
Fault-tolerance. The FOX ring actually consists of two separate, bidirectional, fiberoptic rings. Because the rings are bidirectional, four paths are available between
systems. The FOX ring continues to operate even if three of the four paths fail.
Very high throughput. The FOX fiber-optic cable consists of four fibers working in
parallel (sending and receiving in both directions).
Low host processor impact. Because data packet switching and forwarding are
performed by the ServerNet/Fiber eXtension (ServerNet/FX) adapters, and not by
software processes, processor utilization is more efficient.
Connectivity to existing FOX rings. The Expand-over-FOX line-handler process
provides connectivity to an existing FOX ring that consists of Cyclone and NonStop
K- and S-series servers.
The major disadvantages of FOX connections are that FOX networks are limited in
size (14 systems maximum) and the cost of FOX hardware is relatively high compared
to the hardware used by other connection methods. Also, FOX links can only be used
by the Expand subsystem. FOX links cannot be used in multi-line paths.
A NonStop S-series server can only exchange data directly over a FOX connection
with D-series systems that are running the D30 or later versions of the NonStop Kernel
operating system.
Refer to Time Factors and Pathchange Messages on page 18-24 for information on
adjusting settings so that routing is optimal.
Defining Paths Between Systems
Each system in an Expand network can have up to 255 Expand line-handler
processes. An Expand line-handler process can be configured to handle a single line
or a path consisting of up to eight parallel lines. You can also associate up to 16
Expand line-handler processes in separate processors with one another to form a
multi-CPU path.
This subsection provides information to help you determine when to
•
•
•
•
•
•
Configure a single-line Expand line-handler process
Configure a multi-line path between neighbor nodes
Configure a multi-CPU path
Enable the multipacket frame feature
Enable the variable packet size feature
Enable the congestion control feature
Expand Configuration and Management Manual—523347-008
3 -7
Planning a Network Design
When to Use a Single-Line Expand Line-Handler
Process
When to Use a Single-Line Expand Line-Handler Process
Single-line Expand line-handler processes are less expensive and require somewhat
less processing time than multi-line paths. However, they lack the fault-tolerance that
multi-line paths and multi-CPU paths provide.
When to Use a Multi-Line Path
A path that consists of more than one line is called a multi-line path. A multi-line path
can consist of up to eight parallel lines. The major benefits of configuring a multi-line
path are
•
•
•
Fault-tolerance is increased. If one or more lines in a multi-line path fail, the
Expand subsystem automatically reroutes data over the remaining lines in the
path. You can also attach lines in the path to different hardware communications
devices for an additional level of fault-tolerance.
Bandwidth is increased. The Expand subsystem simultaneously transmits data
over all the lines in a multi-line path, thus increasing overall bandwidth.
Multiple communications methods can be mixed in a multi-line path. You can mix
direct-connect lines, X.25 connections, and SNAX connections in the same multiline path. You cannot mix satellite-connect and Expand-over-IP lines with other line
types. Expand-over-ServerNet and Expand-over-FOX connections cannot be part
of a multi-line path.
The major disadvantages of configuring a multi-line path are
•
•
Overhead is increased. The Expand subsystem uses a packet-queueing algorithm
to select the best line in a multi-line path on which to queue the next packet. This
algorithm requires additional processing time, which is not required by Expand
line-handler processes that manage a single line.
Out-of-sequence (OOS) packet buffering is increased. The frequency of OOS
packets increases when packets are sent over a path that consists of lines of
varying speeds. For example, if the multi-line path contains both 9600 and 56K
byte lines, it is likely that frames traveling on the fast line are received at the
destination ahead of the frames traveling on the slower line. If many OOS packets
are received, the receiving node may require an OOS buffer space that is larger
than the default buffer size. When multipacket frames are used, this situation can
cause frames to be discarded at the destination if the maximum allowable OOS
window is exceeded. For these reasons, you should not configure a path with lines
that vary in speed by more than four to one.
Figure 3-1 illustrates a multi-line configuration with eight dedicated lines and two
ServerNet wide area network (SWAN) concentrators. Four lines are attached to each
SWAN concentrator.
Expand Configuration and Management Manual—523347-008
3 -8
When to Use a Multi-Line Path
Planning a Network Design
Figure 3-1. Multi-Line Path With Eight Lines and Two SWAN Concentrators
$LINE1
$LINE2
SWAN
$LINE3
$LINE4
$PATH1
$LINE5
$LINE6
SWAN
$LINE7
$LINE8
CDT 025.CDD
Expand Configuration and Management Manual—523347-008
3 -9
When to Use a Multi-CPU Path
Planning a Network Design
Figure 3-2 illustrates an eight-line configuration.
Figure 3-2. Multi-Line Path With Eight Lines and Eight SWAN Concentrators
$LINE1
SWAN
$LINE2
SWAN
$LINE3
SWAN
$LINE4
SWAN
$LINE5
SWAN
$LINE6
SWAN
$LINE7
$X25AM1
SWAN
$LINE8
$X25AM2
SWAN
$PATH2
CDT 026.CDD
When to Use a Multi-CPU Path
The Expand multi-CPU feature enables you to connect multiple Expand line-handler
processes, each in a separate processor, between two nodes.
The major benefits of configuring a multi-CPU path are
•
•
Fault-tolerance is increased. If one or more paths in a multi-CPU path fail, the
Expand subsystem automatically reroutes data over the remaining paths. You can
also attach paths to different hardware communications devices for an additional
level of fault-tolerance.
The communications load is shared among multiple processors. Each Expand
line-handler process (or multi-line path) that is a member of a multi-CPU path is
configured in a different processor so, unlike multi-line paths, no single processor
handles all of the processing for the path.
Expand Configuration and Management Manual—523347-008
3- 10
When to Use a Multi-CPU Path
Planning a Network Design
•
Maximum throughput is significantly increased, especially for Expand-over-IP
connections. An Expand-over-IP line-handler process and its associated NonStop
TCP/IP process must be configured in the same processor pair, placing the burden
of processing the entire communications protocol stack for each Expand-over-IP
line on one processor. A multi-line path consisting of Expand-over-IP lines cannot
achieve the throughput of a multi-CPU path because the NonStop TCP/IP
processes associated with the additional lines also must reside in the same
processor.
For more information about configuring Expand-over-IP line-handler processes,
refer to Section 7, Configuring Direct-Connect and Satellite-Connect Lines.
•
•
Bandwidth is increased. Traffic between neighbor nodes is distributed over all the
paths in a multi-CPU path, thus increasing overall bandwidth.
Multiple communications methods can be mixed in a multi-CPU path. Directconnect lines, satellite-connect lines, Expand-over-X.25 connections, Expand-overSNA connections, Expand-over-IP connections, and multi-line paths can be
members of a multi-CPU path. Expand-over-ServerNet and Expand-over-FOX
connections cannot be part of a multi-CPU path.
The major disadvantage of configuring a multi-CPU path is increased overhead. $NCP
periodically runs a rebalancing algorithm that reconsiders the pairings of Expand line
handlers on each multi-CPU path. If the load is unbalanced, $NCP selects different
pairs of line handlers. This algorithm requires additional processing time, which is not
required by Expand line-handler processes that manage multiple lines, and can be
slightly disruptive.
Figure 3-3 shows a multi-CPU path that consists of three paths between nodes \A and
\B. Each Expand line-handler process that is a member of the multi-CPU path is
configured in a separate processor.
Figure 3-3. Multi-CPU Path With Three Paths
Node \A
CPU 0
Node \B
CPU 1
LH
CPU 3
CPU 2
LH
CPU 4
LH
CPU 0
CPU 3
LH
CPU 1
CPU 4
LH
CPU 2
LH
CDT 054.CDD
Expand Configuration and Management Manual—523347-008
3- 11
Planning a Network Design
Selecting Special Features
For more information about multi-CPU paths, refer to Multi-CPU Feature on
page 18-74.
Note. You use the SUPERPATH_ON modifier to configure an Expand line-handler process as
part of a multi-CPU path. If you configure parallel paths between two nodes without using the
SUPERPATH_ON modifier, only one path is used at a given time.
Selecting Special Features
The Expand subsystem includes several special features that enable you to profoundly
affect the operation of your network. These features include the
•
•
•
Multipacket frame feature
Variable packet size feature
Congestion control feature
This subsection provides information to help you determine when to use these
features.
Multipacket Frame Feature
The multipacket frame feature is a performance enhancement designed to increase
throughput and decrease processor overhead for all connection types.
The multipacket frame feature is especially suited for paths in which the default frame
size of 132 words (256-byte packets) is used. For this kind of path, a large increase in
throughput, along with less total processor consumption, should be obtained for a
given load. These advantages are achieved by reducing the use of the message
system and requiring less processing by the Expand line-handler process.
The multipacket frame feature can also improve the efficiency of direct-connect and
satellite-connect lines in which the average message size is less than 500 bytes. For
these types of connections, the multipacket frame feature decreases the number of
interrupts, reduces the number of times the Expand line-handler process is dispatched,
and causes a reduction in processor use.
Online transaction processing (OLTP) benefits the most from the multipacket frame
feature.
For a complete technical overview of the multipacket frame feature, refer to Multipacket
Frame Feature on page 18-64.
Expand Configuration and Management Manual—523347-008
3- 12
Planning a Network Design
Variable Packet Size Feature
Variable Packet Size Feature
The variable packet size feature is a performance enhancement designed to increase
bulk transfers over all connection types.
The variable packet size feature provides the following benefits:
•
•
•
Reduces per-message processor cost for large message sizes
Reduces network bandwidth used for Expand overhead for large messages
Increases potential throughput in high-bandwidth Expand paths
The variable packet size feature allows you to configure a maximum packet size, which
is used for both single-packet and multipacket frames, on a per-path basis. This
feature effectively overrides the packet size calculated from the FRAMESIZE modifier
value.
For a complete technical overview of the variable packet size feature, refer to Variable
Packet Size Feature on page 18-68.
Congestion Control Feature
Congestion control provides improved throughput over LANs and other networks that
are subject to varying delays. It also improves the response time for message transfers
and provides a more efficient error-recovery mechanism. HP recommends that the
congestion control feature be enabled for Expand-over-IP connections and for Expand
line-handler processes that are members of a multi-CPU path.
For a complete technical overview of the congestion control feature, refer to
Congestion Control Feature on page 18-71.
Designing the Network Topology
The pattern of interconnection of systems in a network is called the network topology.
Your goals when designing a network topology should include
•
•
•
•
Minimizing communications costs
Minimizing response time
Satisfying the throughput requirements of networked applications
Achieving a satisfactory level of network reliability
Common Network Topologies
Several topologies can be used in the design of computer networks:
•
•
•
•
•
•
Star
Split-Star
Tri-star
Tree
Ring
Bus
Expand Configuration and Management Manual—523347-008
3- 13
Common Network Topologies
Planning a Network Design
•
•
Mesh
Mixed
The star, tree, ring, bus, and mesh topologies are illustrated in Figure 3-4. A mixed
topology is a combination of more than one type of topology. The split-star and tri-star
topologies are extensions of the star topology.
Figure 3-4. Common Network Topologies
STAR
TREE
RING
BUS
MESH
VST028
Star Topology
In a star topology, all systems join at a central node, creating a star-shaped
configuration. Because all nodes are connected through the central node, a star
network’s reliability depends on the central node; if the central node fails, the entire
network fails.
Expand Configuration and Management Manual—523347-008
3- 14
Planning a Network Design
Common Network Topologies
Split-Star Topology
Used for ServerNet clusters, the split-star topology connects two star topologies. Each
star contains a cluster switch. The two cluster switches are connected by fiber optic
cables, each of which can be up to one kilometer in length. This topology can be used
for more than nine and fewer than 16 nodes. For examples of this topology, refer to
Section 4, Planning for ServerNet Clusters.
Tri-Star Topology
Used for ServerNet clusters, the tri-star topology connects three star topologies. Each
star contains a cluster switch. The three cluster switches are connected by fiber optic
cables, each of which can be up to one kilometer in length. This topology can be used
for up to 24 nodes. For examples of this topology, refer to Section 4, Planning for
ServerNet Clusters.
Tree Topology
In a tree topology, the shape of the network is that of an upside-down tree that has
branches and subbranches. Network reliability in tree networks depends on the
reliability of each connection.
Ring Topology
In a ring topology, nodes are connected in a circle pattern. In a traditional ring topology
of point-to-point links, network reliability depends on the reliability of each connection
along the ring. A FOX ring is a specialized type of ring topology. A node in a FOX ring
must be logically connected to every other node in the FOX ring (a logical, fully
connected mesh). FOX rings are more reliable than most ring topologies because each
node is connected by two bidirectional links. For more information about FOX rings,
refer to Fiber-Optic Cables on page 2-6.
Bus Topology
A bus topology is a common local area network (LAN) topology that consists of a line
of cable with nodes connected along the cable’s entire length.
Mesh Topology
In a mesh topology, each node is connected to every other node in the network. A
mesh network is very reliable because it contains multiple paths between every node.
The major disadvantage of a mesh topology is its high communications cost.
Mixed Topology
A mixed, or unconstrained, topology is a combination of some or all of the abovementioned topologies.
Expand Configuration and Management Manual—523347-008
3- 15
Planning a Network Design
Topology Limitations
Topology Limitations
With the exception of FOX networks (which are always configured in a ring topology),
Expand networks are not limited to any particular network topology. However, the
resource limitations described below can affect your network topology design.
Expand Line-Handler Process Limitation
Because each system in an Expand network can contain a maximum of 255 Expand
line-handler processes, each node can have a maximum of 254 neighbors. This
restriction limits the size of any network configured as a fully connected mesh to 255
nodes.
FOX Network Limitations
A FOX ring can have a maximum of 14 servers and must be configured in a physical
ring topology. Each server in a FOX ring must be logically connected to every other
server in the FOX ring (a logical fully connected mesh). Servers in the ring can be up to
4 kilometers apart.
Creating a Network Diagram
Before you configure your Expand network, HP recommends that you create a diagram
of the complete network topology. This network diagram shows the network nodes and
the lines that connect the nodes. This type of diagram can help you and the operations
staff monitor systems, recognize problems, and prepare for configuration changes.
Figure 3-5 shows one way to create a network diagram. Network diagrams should
show system names, system numbers, communications hardware device names, and
Expand line-handler process names.
Note. System names and numbers are configured through the SCF interface to the NonStop
Kernel subsystem. See the SCF Reference Manual for the Kernel Subsystem for more
information about configuring system names and numbers.
Expand Configuration and Management Manual—523347-008
3- 16
Creating a Network Diagram
Planning a Network Design
Figure 3-5. Network Diagram
\LA
Node1
\DALLAS
Node 2
$PATH1
$PATH1
$LINE1
$LINE1
$LINE2
$LINE2
$LINE3
$LINE3
SWAN
SWAN
$LINEA
$LINEB
SWAN
SWAN
SWAN
SWAN
$LINEA
$LINEB
SWAN
$LINEC
\BOISE
Node 3
SWAN
$LINEC
\CHICAGO
Node 4
CDT 030.CDD
Expand Configuration and Management Manual—523347-008
3- 17
Planning a Network Design
Creating a Network Diagram
Expand Configuration and Management Manual—523347-008
3- 18
4
Planning for ServerNet Clusters
This section describes how to plan for the configuration of Expand over ServerNet
clusters, discusses considerations for ServerNet topologies, and provides examples of
configuring Expand over ServerNet clusters, ServerNet clusters in combination with
ServerNet/FX, ServerNet clusters in combination with ATM and IP networks, and
ServerNet clusters with other communication methods.
You can configure Expand over ServerNet clusters by using either OSM or SCF. The
ServerNet Cluster Manual (for the 6770 cluster switch) and the ServerNet Cluster 6780
Planning and Installation Guide provide procedures for configuring Expand over
ServerNet clusters and information about recommended ServerNet cluster topology
configurations.
This section refers to the network control process ($NCP). $NCP initiates and
terminates node-to-node connections, maintains routing information, selects the bestpath route for data transmission to other nodes in the network, and monitor and logs
changes in the status of the network and its nodes. See Section 6, Configuring the
Network Control Process, for more information.
This section does not address every possible topology or identify every process that
must be running on each system. For additional information, refer to the following
manuals:
Cluster Switch
Manual
6770
ServerNet Cluster Manual
6780
ServerNet Cluster 6780 Planning and Installation Guide
The topics described in this section include:
•
•
•
Configuration Considerations for Expand and ServerNet Clusters on page 4-1
ServerNet Clusters Coexisting With FOX Rings on page 4-3
ServerNet Clusters Coexisting With ATM or IP Networks on page 4-6
Configuration Considerations for Expand and
ServerNet Clusters
Major configuration considerations for Expand and ServerNet clusters include:
•
A route between two nodes that involves a change in technology invokes the use
of the Expand line handlers at every node along the route (including the source
and destination nodes). A change in technology might be a change from an
Expand-over-ServerNet line to an Expand-over-ATM line or from an Expand-overServerNet line to an Expand over FOX line.
Expand Configuration and Management Manual—523347-008
4 -1
Planning for ServerNet Clusters
•
•
•
•
•
•
•
Configuration Considerations for Expand and
ServerNet Clusters
Every Expand system number and name must be unique across all networks that
can use Expand to communicate.
Each system in an Expand network can support up to 255 Expand line-handler
processes.
A node can only belong to one ServerNet cluster.
The Expand manager process, $ZEXP, must be configured and started.
The NonStop ServerNet cluster monitor process, $ZZSCL, must be configured and
started in all S-series nodes connected to a ServerNet cluster.
As of G06.20, the Expand routing rules have reverted to the use of simple time
factors. Super time factors, which were based on SPEEDK attributes, are no
longer used. SPEEDK values are now translated into line time factors that have
values from 0 to 186. See also, Considerations for ServerNet Clusters Coexisting
With ServerNet/FX on page 4-3.
You must evaluate the distance restrictions between cluster switches and
ServerNet cluster nodes during the planning process. Distance restrictions for
cabling ServerNet clusters are not shown in the topology examples in this section;
refer to the ServerNet Cluster Manual (for the 6770 switch) and the ServerNet
Cluster 6780 Planning and Installation Guide for information about cable-distance
restrictions in ServerNet clusters.
Expand-over-ServerNet line-handler process modifier considerations include:
•
•
FRAMESIZE n modifier: This modifier must be the same for every Expand
line-handler process on every node in the Expand network.
PATHTF n, LINETF n, SPEEDK n, SPEED n, and RSIZE n, modifiers: These
modifiers set the time factor (TF) for an Expand line. $NCP uses TFs to make
routing decisions. If PATHTF, LINETF, or RSIZE are specified, the value is the time
factor; if SPEEDK or SPEED are specified, the time factor is calculated.
LINETF is the recommended setting for ServerNet lines. PATHTF is equivalent to
LINETF for ServerNet lines. They each have a range of 0 to 186 to designate a
time factor in selecting the best lines and paths to other nodes; the smaller the
number, the more desirable the path.
When you use LINETF, you are setting the time factors directly. For example, if you
prefer to use ServerNet as the best line, ATM as the second best line, and FOX as
the third best line, you would set the LINETF as 1 for ServerNet, 2 for ATM, 3 for
FOX, and a value greater than 3 for all the other paths.
See Routing and Time Factors on page 18-22 for more information about time
factors, including how they are specified and calculated.
Expand Configuration and Management Manual—523347-008
4 -2
Planning for ServerNet Clusters
ServerNet Clusters Coexisting With FOX Rings
ServerNet Clusters Coexisting With FOX Rings
Interoperability is supported between a ServerNet cluster and a FOX ring containing
ServerNet/FX 2 adapters. This subsection addresses the following topics:
•
•
Considerations for ServerNet Clusters Coexisting With ServerNet/FX on page 4-3
Examples of ServerNet Clusters Coexisting With FOX Rings on page 4-4
For information about ServerNet /FX adapters, see the ServerNet/FX Adapter
Configuration and Management Manual.
Considerations for ServerNet Clusters Coexisting With
ServerNet/FX
•
•
•
•
•
In general, grouping any NonStop K-series systems on the FOX ring can further
reduce message latencies and minimize use of the FOX ring.
When you plan to mix ServerNet clusters with ServerNet/FX, consider the
throughput requirements of networked applications. Since a network can consist of
a combination of data communication methods, having traffic travel along a specific
route can increase network performance by avoiding nodes where increased
processor use would create a bottleneck. A specific route between nodes can be
forced by configuring the LINETF modifier with a different value on each Expandover-ServerNet line. Varying the value of the LINETF modifier varies the time factor
(TF) associated with each line.
Low message latencies and high performance can be achieved by configuring
systems that communicate often with each other to be part of the same ServerNet
cluster. When systems are part of different ServerNet clusters but connected to the
same FOX ring and need to communicate with each other, the messages bypass
the Expand subsystem and are handled directly by the ServerNet/FX adapters
through the FOX ring.
SPEEDK values that are set greater than FOX result in a time factor of 1. For more
information, refer to Routing and Time Factors on page 18-22.
As of G06.20, the Expand routing rules have reverted to the use of simple time
factors. When ServerNet clusters coexist with ServerNet/FX on G06.20 or later
RVUs, you must set the FOX line time factors to 2 or more to avoid a conflict with
the ServerNet cluster time factors (normally set at 1).
Expand Configuration and Management Manual—523347-008
4 -3
Planning for ServerNet Clusters
Examples of ServerNet Clusters Coexisting With
FOX Rings
Examples of ServerNet Clusters Coexisting With FOX Rings
The ferris-wheel topology is recommended when a ServerNet cluster needs to coexist
with a FOX ring. This topology provides fault-tolerant communication between all
nodes, high performance, low processor utilization, and low message latencies.
The following examples are provided in this subsection:
•
•
ServerNet Cluster Inside a FOX Ring on page 4-4
ServerNet Cluster and FOX Ring Connected By One NonStop S-Series System
(Not Recommended) on page 4-5
ServerNet Cluster Inside a FOX Ring
When NonStop S-series systems are combined with NonStop K-series systems in a
FOX ring, you should add the NonStop S-series servers to the FOX ring as well as to
the ServerNet cluster to reduce message latency for transmissions between the two
server types. By adding the NonStop S-series servers to the FOX ring, the NonStop
S-series servers can communicate with each other by using clustering technology and
can communicate with the NonStop K-series servers by using the FOX ring. Using the
same communication technology to communicate between the different server types
reduces latency and speeds transmission times by eliminating a line hop.
For example, if you have four FOX-connected systems, two of which are NonStop
S-series servers and two of which are NonStop K-series servers, and you want to add
four NonStop S-series servers and ServerNet clustering technology, adding the new
servers to the FOX ring as well as to the ServerNet cluster speeds transmission times
by allowing the NonStop S-series servers and NonStop K-series servers to
communicate with each other over FOX. This configuration, shown in Figure 4-1,
eliminates the line hop that would occur to switch from the ServerNet cluster to the
FOX ring for messages travelling between the different server types.
Expand Configuration and Management Manual—523347-008
4 -4
Examples of ServerNet Clusters Coexisting With
FOX Rings
Planning for ServerNet Clusters
Figure 4-1. ServerNet Cluster Inside a FOX Ring
\BBB #2
NonStop
S-series
\AAA #1
NonStop
S-series
\CCC #3
NonStop
S-series
\HHH #8
NonStop
S-series
Cluster
switch
\DDD #4
NonStop
K-series
\GGG #7
NonStop
S-series
\EEE #5
NonStop
K-series
\FFF #6
NonStop
S-series
VST068
Expand sees the NonStop K-series as only one hop away even when it is several hops
away. In addition, if a message has to travel between a NonStop S-series server and a
NonStop K-series server, and both FOX and ServerNet clusters are available, Expand
always chooses FOX because, based on time factors, Expand sees ServerNet clusterto-FOX transmissions as having a time factor of 1 plus 2 (3) but sees FOX-to-FOX
transmissions as having a time factor of just 2.
Grouping NonStop K-series servers together also speeds transactions.
Note. You can extend the example shown in Figure 4-1 to multiple cluster switches and
servers.
ServerNet Cluster and FOX Ring Connected By One
NonStop S-Series System (Not Recommended)
The topology shown in Figure 4-2 is not recommended for connecting a ServerNet
cluster to an existing FOX ring. Processor use is higher whenever traffic flows between
\BBB, \CCC, or \EEE and \AAA, \DDD, or \FFF. For example, when \DDD requests
information from \CCC, four Expand line handlers are invoked: one in \DDD, two in
\HHH, and one in \CCC.
Expand Configuration and Management Manual—523347-008
4 -5
ServerNet Clusters Coexisting With ATM or IP
Networks
Planning for ServerNet Clusters
Line-handler passthrough traffic uses at least twice as much processor time as does
direct traffic. Overall network fault tolerance is not preserved. If \HHH becomes
unavailable, the FOX ring and the ServerNet cluster are isolated from each other.
Figure 4-2. ServerNet Cluster and FOX Ring Connected By One NonStop
S-Series System (Not Recommended)
FOX Ring
ServerNet Cluster
\BBB #2
NonStop
S-series
\AAA #1
NonStop
S-series
\CCC #3
NonStop
K-series
\HHH #8
NonStop
S-series
\EEE #5
NonStop
K-series
Cluster
Switch
\DDD #4
NonStop
S-series
\FFF #6
NonStop
S-series
VST070
ServerNet Clusters Coexisting With ATM or IP
Networks
Interoperability is supported between a ServerNet cluster and an ATM network using
ATM adapters or between a ServerNet cluster and an IP network using Ethernet, Fast
Ethernet, Gigabit Ethernet, or ATM adapters. These technologies allow the following:
•
•
•
•
Connection over distances greater than five kilometers
Use of TCP for internode communications (the IP technology)
Reduction of line costs
Interoperability between NonStop K-series servers and NonStop S-series servers
(the IP technology)
The topics addressed in this subsection include:
•
•
Considerations for ServerNet Clusters Coexisting With ATM or IP on page 4-7
Examples of ServerNet Clusters Coexisting With ATM or IP on page 4-7
For information about IP and ATM adapters, see the following manuals:
TCP/IPv6 Configuration and Management Manual
TCP/IP (Parallel Library) Configuration and Management Manual
TCP/IP Configuration and Management Manual
ATM Configuration and Management Manual
Expand Configuration and Management Manual—523347-008
4 -6
Planning for ServerNet Clusters
Considerations for ServerNet Clusters Coexisting
With ATM or IP
Considerations for ServerNet Clusters Coexisting With ATM
or IP
•
•
•
Traffic can be distributed in a balanced fashion over the ATM or IP lines by
appropriately configuring the time factors (TFs). For information about configuring
time factors, refer to Routing and Time Factors on page 18-22.
Be careful when mixing these technologies to ensure a fault-tolerant topology and
to prevent bottlenecks at the inter-technology connection points.
If you want to expand your ServerNet cluster by adding nodes, HP recommends
that you use the guided procedure. To add a node by using TSM, go to the system
console of the system you are adding, select Start>program>Compaq
TSM>Guided Configuration Tools>Configure ServerNet Node. Online help is
available to assist you in performing the procedure. To add a node by using the
OSM Service Connection, log onto the system being added, select the Configure
a ServerNet Node action for the System object, and perform the action. A guided
procedure is launched, with online help available to assist you in performing the
procedure.
Note. For the layered topology, you must use OSM.
Examples of ServerNet Clusters Coexisting With ATM or IP
The following examples are provided in this subsection:
•
•
•
ServerNet Clusters Connected By ATM or IP Lines on page 4-7
ServerNet Clusters Connected By a Single ATM or IP Line (Not Recommended) on
page 4-8
ServerNet Clusters Using Layered Topology With Connections to Nodes Outside
the Cluster on page 4-9
ServerNet Clusters Connected By ATM or IP Lines
All the systems in Figure 4-3 are NonStop S-series systems.
Groups of systems at separate locations can use clustering technology to increase
performance within each location and connect to each other by using ATM or IP lines.
When systems on different ServerNet clusters need to communicate with each other,
the Expand line handlers are invoked at every node along the path between the source
and the destination node (including the source and destination nodes). Thus,
processor use is higher when networked applications transfer information between
systems located on separate ServerNet clusters. To avoid this situation, you can
provide the ATM or IP connectivity within the ServerNet cluster so that communications
between the ServerNet clusters travels over IT or ATM without invoking line handlers to
change technologies. Figure 4-3 shows two ATM-connected or IP-connected
ServerNet clusters in a configuration that incurs line hops. To modify this configuration
Expand Configuration and Management Manual—523347-008
4 -7
Examples of ServerNet Clusters Coexisting With
ATM or IP
Planning for ServerNet Clusters
for inter-ServerNet cluster communications without line hops, add ATM or IP
connections within the ServerNet cluster as well.
In Figure 4-3, note that the multiple inter-ServerNet cluster of ATM connections or IP
connections produces a fault-tolerant design.
Figure 4-3. ServerNet Clusters Connected by ATM or IP Lines
5-Node ServerNet Cluster
4-Node ServerNet Cluster
ATM or IP
\BBB #2
\CCC #3
Cluster
Switch
\FFF #4
\EEE #5
\HHH #6
ATM
or IP
\AAA #1
\DDD #7
ATM or IP
Cluster
Switch
\GGG #9
\JJJ #8
ATM or IP
VST062
ServerNet Clusters Connected By a Single ATM or IP Line
(Not Recommended)
All the systems in Figure 4-4 are NonStop S-series systems.
This topology is not recommended as a solution for enabling communication between
two ServerNet clusters due to higher processor use, traffic bottlenecks, and a lack of
overall network fault tolerance.
Processor use is higher whenever traffic flows between the two ServerNet clusters due
to a technology change between \HHH and \DDD which causes the Expand line
handlers to be used at every node on the route (including the source and destination
nodes). For example, when \GGG requests information from \CCC, six Expand line
handlers are invoked: one in \GGG, two in \DDD, two in \HHH, and one in \CCC.
Line-handler passthrough traffic uses at least twice as much processor time as does
direct traffic. Traffic bottlenecks can occur at \HHH and \DDD when numerous requests
for information are made by systems located on separate ServerNet clusters. Overall
network fault tolerance is not preserved. If \HHH or \DDD becomes unavailable, the
two ServerNet clusters are isolated from each other.
Expand Configuration and Management Manual—523347-008
4 -8
Examples of ServerNet Clusters Coexisting With
ATM or IP
Planning for ServerNet Clusters
Figure 4-4. ServerNet Clusters Connected by a Single ATM or IP Line (Not
Recommended)
5-Node ServerNet Cluster
4-Node ServerNet Cluster
\BBB #2
\AAA #1
\CCC #3
Cluster
Switch
\FFF #4
\EEE #5
\HHH #6
ATM
or IP
\DDD #7
Cluster
Switch
\GGG #9
\JJJ #8
VST063
ServerNet Clusters Using Layered Topology With
Connections to Nodes Outside the Cluster
In this example, all the systems directly connected to the cluster switches are NonStop
S-series systems. (See Figure 4-5.)
This ServerNet cluster uses the layered topology (for more information about the
layered topology, see the ServerNet Cluster 6780 Planning and Installation Guide ).
\Z123, \Z456, and \Z789 can be NonStop K-series servers (IP lines) or NonStop
S-series servers (ATM or IP lines).
The Expand line handlers in \BBB and \EEE (depending on $NCP’s determination of
the best-path route to \Z123) can become heavily stressed if other systems in the
ServerNet cluster frequently communicate with \Z123. (The same condition applies to
Expand line handlers in the ServerNet cluster nodes that communicate with \Z456 and
\Z789.) To avoid these potential bottlenecks, you can run ATM or IP within the
ServerNet cluster. Then, these lines are used to communicate with nodes outside the
ServerNet cluster.
Expand Configuration and Management Manual—523347-008
4 -9
Examples of ServerNet Clusters Coexisting With
ATM or IP
Planning for ServerNet Clusters
Figure 4-5. ServerNet Cluster Using Layered Topology With Connections to
Nodes Outside the Cluster
ATM or IP
\AAA
Zone 1
\GGG
\BBB
Cluster Switch
Group
\HHH
\CCC
\III
\Z123
Layer 2
Layer 1
\DDD
\JJJ
\EEE
\LLL
\FFF
\MMM
ATM or IP
Zone 2
Zone 3
Cluster Switch
Group
\NNN
Cluster Switch
Group
\SSS
\AAB
\TTT
\BBC
\PPP
\UUU
\CCD
\HHI
\QQQ
\VVV
\DDE
\IIJ
\RRR
\WWW
\EEF
\JJK
\OOO
Layer 2
Layer 1
\Z456
ATM or IP
\FFG
Layer 2
Layer 1
\GGH
\Z789
ATM or IP
ATM or IP
ATM or IP
VST075
Expand Configuration and Management Manual—523347-008
4- 10
Part II. Configuring the Expand
Subsystem
Part II consists of the following sections, which provide an overview of the configuration
process and explain how to configure the various types of Expand line-handler
processes:
Section 5
Configuration Overview
Section 6
Configuring the Network Control Process
Section 7
Configuring Direct-Connect and Satellite-Connect Lines
Section 8
Configuring Expand-Over-IP Lines
Section 9
Configuring Expand-Over-ATM Lines
Section 10
Configuring Expand-Over-X.25 Lines
Section 11
Configuring Expand-Over-SNA Lines
Section 12
Configuring Expand-Over-ServerNet Lines
Section 13
Configuring Expand-Over-FOX Lines
Section 14
Configuring Multi-Line Paths
Expand Configuration and Management Manual—523347-008
Part II. Configuring the Expand Subsystem
Expand Configuration and Management Manual—523347-008
5
Configuration Overview
This section provides an overview of the Expand subsystem configuration process.
Before using this section and the remaining sections in this manual, you should be
familiar with the following:
•
•
•
•
Section 3, Planning a Network Design. This section describes network design
considerations such as selecting line protocols. You should design your network
and create a network diagram before attempting to perform the tasks described in
this and the remaining sections of this manual.
Section 4, Planning for ServerNet Clusters. This section provides Expand and
ServerNet Cluster configuration considerations and presents topology examples of
ServerNet Clusters coexisting with other Expand networks. You should be familiar
with this section before you design a network topology that includes ServerNet
Clusters.
Section 17, Expand Modifiers. This section provides many modifiers for linehandler processes that enable you to customize your network. You should be
familiar with the information presented in this section before you add new modifiers
or change the default values of Expand modifiers in your configuration. Modifiers
that affect the network control process ($NCP) are discussed in Section 6,
Configuring the Network Control Process.
Section 18, Subsystem Description. This section provides a high-level technical
description of the architecture and dynamics of the Expand subsystem. You should
be familiar with the information presented in this section before you attempt to
configure, manage, or troubleshoot the Expand subsystem.
Expand Configuration and Management Manual—523347-008
5 -1
Summary of Configuration Steps
Configuration Overview
Summary of Configuration Steps
Configuring the Expand subsystem involves a number of steps. Table 5-1 lists each
step and indicates where in this manual the step is described.
Table 5-1. Configuration Steps
Step
Description
Where This Step Is Described
1.
Start the Expand manager
process.
For step 1, information is located in Starting the
Expand Manager Process on page 5-4 of this
section.
2.
Create a profile for the
network control process at
each node in the Expand
network.
For steps 2 and 3, information is located in
Section 6, Configuring the Network Control
Process.
3.
Create and start the
network control process at
each node in the Expand
network.
4.
Create profiles for the
Expand line-handler
processes.
For steps 4 through 6, information is located in one
of the following sections. Which section you select
depends on the type of Expand line-handler
process that you want to configure:
5.
Create and start the Expand
line-handler processes.
Section 7, Configuring Direct-Connect and SatelliteConnect Lines
6.
Start the Expand lines.
Section 8, Configuring Expand-Over-IP Lines
Section 9, Configuring Expand-Over-ATM Lines
Section 10, Configuring Expand-Over-X.25 Lines
Section 11, Configuring Expand-Over-SNA Lines
Section 12, Configuring Expand-Over-ServerNet
Lines
Section 13, Configuring Expand-Over-FOX Lines
Section 14, Configuring Multi-Line Paths
Expand Configuration and Management Manual—523347-008
5 -2
Creating a Profile
Configuration Overview
Creating a Profile
A profile template is a disk file that contains modifiers and default modifier values. HP
provides profile templates for the network control process ($NCP) and for the different
types of Expand line-handler processes.
Table 5-2 lists the profile templates for the Expand subsystem. These profile templates
are installed in $SYSTEM.SYSnn. The modifiers in each profile template are described
in the sections listed in Table 5-1. A comprehensive list of all the Expand modifiers is
provided in Section 17, Expand Modifiers.
Table 5-2. Expand Profile Templates
Disk
Filename
Description
Device Type and
Subtype
PEXPNCP
Network control process modifiers
62,6
PEXQSSWN
Direct-connect modifiers (single-line)
63,5
PEXQMSWN
Direct-connect modifiers (line-logical device)
63,6
PEXQSSAT
Satellite-connect modifiers (single-line)
63,5
PEXQMSAT
Satellite-connect modifiers (line-logical device)
63,6
PEXQSNAM
Expand-over-NAM modifiers (single-line)
63,0
PEXQMNAM
Expand-over-NAM modifiers (line-logical device)
63,2
PEXQSIP
Expand-over-IP modifiers (single-line)
63,0
PEXQMIP
Expand-over-IP modifiers (line-logical device)
63,2
PEXQSATM
Expand-over-ATM modifiers (single-line)
63,0
PEXQMATM
Expand-over-ATM modifiers (line-logical device)
63,2
PEXPPATH
Path logical device modifiers
63,1
PEXPSSN
Expand-over-ServerNet modifiers
63,4
PEXQSFX
Expand-over-FOX modifiers
63,3
You can create a profile from one of the profile templates listed in Table 5-2, from a
previously created profile, or you can create your own profile. You create a profile
using the WAN subsystem SCF ADD PROFILE command. This command allows you
to specify the modifiers and modifier values that will be contained in the profile you are
creating. You can display the contents of a specific profile using the WAN subsystem
SCF INFO PROFILE command.
For more information about WAN subsystem SCF commands, refer to the WAN
Subsystem Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
5 -3
Configuration Overview
Creating Wide Area Network (WAN) Subsystem
Devices
Creating Wide Area Network (WAN) Subsystem
Devices
The network control process and Expand line-handler processes are defined as WAN
subsystem devices. The DEVICE object represents $NCP and Expand line-handler
processes in the WAN subsystem. You use the WAN subsystem SCF ADD DEVICE
command to create the network control process and Expand line-handler processes.
When you create a device using the SCF ADD DEVICE command, you must specify
the profile that the device will use. Multiple devices can use the same profile, allowing
you to create one profile for each type of Expand line-handler process. For example,
you could create a profile named SLHDIR to be used by all direct-connect line-handler
processes. The WAN subsystem SCF INFO PROFILE command lists the devices that
use a specific profile.
The SCF ADD DEVICE command also enables you to specify modifiers and modifier
values that will be used only by the device you are creating. These modifiers and
modifier values are part of the device record for the device and can be different from
the modifiers and modifier values in the profile used by the device. The modifiers and
modifier values used by a specific device are displayed by the Expand subsystem SCF
INFO PATH and INFO LINE commands. You can also display device-specific modifiers
using the WAN subsystem SCF INFO DEVICE command with the DETAIL option.
For more information about WAN subsystem SCF commands, refer to the WAN
Subsystem Configuration and Management Manual. For more information about
Expand subsystem SCF commands, refer to Section 15, Subsystem Control Facility
(SCF) Commands.
Starting the Expand Manager Process
The Expand subsystem requires that the Expand manager process ($ZEXP) be
running during network operation. To start the Expand manager process, enter the
following command at the TACL prompt:
RUN $SYSTEM.SYSnn.OZEXP / NAME $ZEXP, PRI 180, NOWAIT, CPU primary / backup
where primary is the number of the processor where the primary process will run and
backup is the processor where the backup process will run.
You can also start the Expand manager process at system startup by including the
following command in the system startup file:
OZEXP / NAME $ZEXP, OUT $ZHOME, PRI 180, NOWAIT, CPU primary / backup
To verify that the process is started, enter the TACL process-pair directory (PPD)
command at the TACL prompt:
PPD $ZEXP
Expand Configuration and Management Manual—523347-008
5 -4
6
Configuring the Network Control
Process
This section explains how to configure and start the network control process ($NCP).
Configuring and starting $NCP involves the following steps:
Step 1: Create a Profile for $NCP on page 6-1
Step 2: Create $NCP on page 6-2
Step 3: Start $NCP on page 6-4
You perform all these steps using the SCF interface to the WAN subsystem. This
section also describes the $NCP profile modifiers in $NCP Modifiers on page 6-4.
Step 1: Create a Profile for $NCP
You can create a profile for $NCP by using the PEXPNCP profile in $SYSTEM.SYSnn.
This step shows how to create a profile using the PEXPNCP profile.
Note. You can also create a new profile from an existing profile, or you can create your own
profile. For complete information about profiles, refer to the WAN Subsystem Configuration and
Management Manual.
ADD Profile Command
To create a profile from the PEXPNCP profile template, use the WAN subsystem SCF
ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.PEXPNCP
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters to be used to identify the new profile. You will reference
this profile name when you create $NCP in Step 2: Create $NCP.
FILE $SYSTEM.SYSnn.PEXPNCP
specifies the name of an existing disk file that will be used to create the new
profile. PEXPNCP is the disk file name of the profile for $NCP.
modifier_keyword
is the name of a $NCP modifier in profile_name. Modifier names in the
PEXPNCP profile are listed in $NCP Modifiers on page 6-4.
Expand Configuration and Management Manual—523347-008
6 -1
Configuring the Network Control Process
Example
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a value in modifier_value assigns a new value to
modifier_keyword in profile_name. Default values and ranges of values for
modifiers in the PEXPNCP profile are described in $NCP Modifiers on page 6-4.
Example
The following example creates a profile named NCPPROF1. The ALGORITHM
modifier in the profile is set to 1 to specify split horizon. For more information, refer to
ALGORITHM n on page 6-5 and Routing Algorithms on page 18-28.
-> ADD PROFILE $ZZWAN.#NCPPROF1, FILE $SYSTEM.SYS01.PEXPNCP, &
ALGORITHM 1
Step 2: Create $NCP
You create $NCP by adding a device to the WAN subsystem.
ADD DEVICE Command
To create $NCP, use the WAN subsystem SCF ADD DEVICE command. The
command syntax is as follows:
ADD
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#NCP
IOPOBJECT $SYSTEM.SYSnn.NCPOBJ
PROFILE profile_name
CPU cpunum
ALTCPU altcpunum
TYPE (62,6)
RSIZE 1
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#NCP
specifies, via the WAN subsystem, the device name of $NCP. This value must be
NCP and must be preceded by the pound sign (#).
IOPOBJECT $SYSTEM.SYSnn.NCPOBJ
is the name of the object file containing the executable object code for $NCP. This
value must be $SYSTEM.SYSnn.NCPOBJ.
PROFILE profile_name
is the name of the profile you created for $NCP in Step 1.
Expand Configuration and Management Manual—523347-008
6 -2
Configuring the Network Control Process
Considerations
CPU cpunum
indicates the processor where $NCP will normally execute. HP recommends that
you configure $NCP to run in processor 0.
ALTCPU altcpunum
indicates the processor where the backup $NCP will normally execute. HP
recommends that you configure the backup $NCP to run in processor 1.
TYPE (62,6)
is the device type and subtype for $NCP. The device type is always 62 and the
subtype is always 6 for $NCP.
RSIZE 1
specifies the time factor of the line for the Expand routing algorithm. The RSIZE
value must be set to 1 for $NCP.
modifier_keyword
is the name of a modifier in profile_name. modifier_keyword is added to the
device record for $NCP.
Modifier names in the PEXPNCP profile are listed in $NCP Modifiers on page 6-4.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
modifier_value assigns a value to modifier_keyword in the device record
for $NCP.
Default values and ranges of values for modifiers in the PEXPNCP profile are
listed in $NCP Modifiers on page 6-4.
Considerations
The modifier_keyword and modifier_value parameters do not add the specified
modifier or its associated value to the profile used by the device. Use the ADD
PROFILE command to add a modifier, or a modifier and its associated value, to a
profile.
Example
The following example creates $NCP. The MAXCONNECTS modifier for the device is
set to 10.
-> ADD DEVICE $ZZWAN.#NCP, IOPOBJECT $SYSTEM.SYS01.NCPOBJ, &
PROFILE NCPPROF1, CPU 0, ALTCPU 1, TYPE (62,6) RSIZE 1, &
MAXCONNECTS 10
Expand Configuration and Management Manual—523347-008
6 -3
Step 3: Start $NCP
Configuring the Network Control Process
Step 3: Start $NCP
To start $NCP, you use the WAN subsystem SCF START DEVICE command. The
command syntax is as follows:
START DEVICE $ZZWAN.#NCP
To make sure $NCP has started successfully, enter the following command at the
TACL prompt:
> STATUS $NCP
If $NCP was started successfully, you will see a display similar to Example 6-1:
Example 6-1. SCF STATUS $NCP Command
System \NODEA
Process
$NCP
3,26
$NCP
2,24
B
Pri PFR %WT Userid
199 P
011 255,255
Swap File Name:
199 P
011 255,255
Swap File Name:
Program file
$SYSTEM.SYS01.NCPOBJ
$SYSTEM.#0
$SYSTEM.SYS01.NCPOBJ
$SYSTEM.#0
Hometerm
$YMIOP.#CLCI
$YMIOP.#CLCI
If $NCP was not started successfully, the following message will be displayed:
(Process does not exist)
$NCP Modifiers
The following modifiers are included in the PEXPNCP profile. These modifiers are
provided to enable you to customize $NCP routing algorithm, select a network map
propagation algorithm, and modify network connection handling.
ABORTTIMER n
Default:
Units:
Range:
15,000 (2.5 minutes)
0.01 seconds
0 to 30,000 (0 to 5 minutes)
This modifier specifies the length of time, in one-hundredth of a second increments,
that $NCP will wait before aborting requests destined for a remote system to which an
alternate path has not yet been identified. The ABORTTIMER modifier must be set to
the same value on all systems in the network.
By setting the ABORTTIMER modifier, you can prevent $NCP from completing
requests with an error 250 (all paths to the system are down) before it has sufficient
time to receive alternate-path information. The ABORTTIMER modifier should be used
with the modified split horizon (MSH) routing algorithm. The ABORTTIMER modifier is
explained in more detail in Modified Split Horizon (MSH) on page 18-28.
Expand Configuration and Management Manual—523347-008
6 -4
Configuring the Network Control Process
$NCP Modifiers
ALGORITHM n
Default:
Units:
Range:
0 (MSH)
Not applicable
0 or 1
This modifier identifies $NCP routing algorithm to be used. Specify 0 for MSH or 1 for
split horizon (SH). The ALGORITHM modifier must be set to the same value on all
systems in the network.
Modified split horizon (MSH) and split horizon (SH) algorithms are explained in detail in
Routing Algorithms on page 18-28.
AUTOMATICMAPTIMER n
Default:
Units:
Range:
1 (on)
Not applicable
0 or 1
This modifier causes $NCP to exchange distance vector (DV) messages at variable
rates, depending on the time factor (TF) of the path involved and the presence or
absence of changes to the network. If you specify 1 (the default), the DV propagation
rate is 8 seconds multiplied by the TF for the path. A value of 0 specifies an algorithm
with a 5-minute propagation interval. The use of DV message exchanges is described
in detail in Regular Maps Exchanges on page 18-27.
CONNECTTIME n
Default:
Units:
Range:
0
0.01 seconds
1,000 through 30,000 (10 seconds to 5 minutes)
This modifier specifies the length of time, in one-hundredth of a second increments,
that $NCP will wait for a response to its connect (CONN) request. If you specify 0 (the
default), $NCP computes the connect request timer independently for each connection
using the following formula:
0.5 * tf_to_destination
tf_to_destination is learned through NETMAPs received from neighboring
systems. You can specify a value in the range 1,000 through 30,000 to set the connect
request timer to a noncomputed number of seconds for all connections.
CONN requests are described in Protocol Packet Types on page 18-13 and TFs are
described in Routing and Time Factors on page 18-22.
Expand Configuration and Management Manual—523347-008
6 -5
Configuring the Network Control Process
$NCP Modifiers
FRAMESIZE n
Default:
Units:
Range:
132
Words
64 through 250
The $NCP FRAMESIZE modifier specifies the maximum packet size that $NCP can
send in the network. This value must be less than or equal to the Expand line-handler
process’s FRAMESIZE modifier but, it cannot be greater than 250. It is not required
that this modifier be the same for each $NCP in the network.
MAXCONNECTS n
Default:
Units:
Range:
5
Not applicable
1 through 255
This modifier specifies the number of CONN requests that can be outstanding on each
path from the system.
MAXTIMEOUTS n
Default:
Units:
Range:
3
Not applicable
1 through 255
This modifier specifies the maximum number of times $NCP will attempt a CONN
request.
NETWORKDIAMETER n
Default:
Units:
Range:
15
Not applicable
1 through 254
This modifier specifies the maximum number of hops (intervening nodes) in a path
between two nodes. You should set n to the longest path between any two nodes in
the network plus one. You should use the NETWORKDIAMETER modifier with the SH
routing algorithm. The NETWORKDIAMETER modifier is explained in detail in Split
Horizon (SH) on page 18-30.
Expand Configuration and Management Manual—523347-008
6 -6
7
Configuring Direct-Connect and
Satellite-Connect Lines
The direct-connect line-handler process implements the High-Level Data Link Control
(HDLC) Normal protocol and operates with conventional voice-grade leased-line and
switched-line facilities, private facilities, and fractional Transmission Group 1 (T1)
facilities. The satellite-connect line-handler process implements the satellite-efficient
version of the HDLC protocol, HDLC Extended mode.
A direct-connect or satellite-connect line-handler process can be configured as a single
line, as part of a multi-line path, or as part of a multi-CPU path. This section explains
how to configure a direct-connect or satellite-connect line-handler process as a singleline or as part of a multi-CPU path. Configuring direct-connect and satellite-connect
lines that are part of a multi-line path is explained in Section 14, Configuring Multi-Line
Paths.
Expand Configuration and Management Manual—523347-008
7 -1
Configuring Direct-Connect and Satellite-Connect
Lines
Required Hardware and Software
Required Hardware and Software
Several hardware and software components are required in addition to the directconnect or satellite-connect line-handler process to provide direct-connect or satelliteconnect connectivity. These components are illustrated in Figure 7-1 and are explained
in the following subsections.
Figure 7-1. Direct-Connect and Satellite-Connect Connectivity Components
Processor
Direct-Connect or
Satellite-Connect LineHandler Process
File-System
Interface
QIO Shared
Memory
Segment
WAN
Shared
Driver
TCP/IP
Process
LAN Driver and Interrupt Handlers
(DIHs)
Y-Fabric
X-Fabric
LAN
Adapter
LAN
Adapter
SWAN
SWAN
VST001
Expand Configuration and Management Manual—523347-008
7 -2
Configuring Direct-Connect and Satellite-Connect
Lines
QIO Subsystem
QIO Subsystem
QIO is a mechanism for transferring data between processes through a shared
memory segment. The QIO subsystem is preconfigured and started during the system
load sequence. The QIO subsystem must be started before Expand line-handler
processes can be started.
For information about the QIO subsystem, refer to the QIO Configuration and
Management Manual.
Wide Area Network (WAN) Shared Driver
The WAN shared driver is a set of library procedures that is bound with each inputoutput process (IOP) that uses a ServerNet wide area network (SWAN) concentrator.
The WAN shared driver is a component of the WAN subsystem. The WAN subsystem
is preconfigured and starting during the system load sequence.
For information about the WAN subsystem, refer to the WAN Subsystem Configuration
and Management Manual.
NonStop TCP/IP Process
The NonStop TCP/IP subsystem provides TCP/IP data communications connectivity.
NonStop TCP/IP processes are used by the following LAN adapters: Ethernet 4
ServerNet adapters (E4SAs), Fast Ethernet ServerNet adapters (FESAs), Gigabit
Ethernet ServerNet adapters (GESAs), Gigabit Ethernet 4-port ServerNet adapters
(G4SAs), and SWAN concentrators. The NonStop TCP/IP processes that support the
E4SAs, FESAs, GESAs, G4SAs, and SWAN concentrators are preconfigured and
started during the system load sequence.
For information about the NonStop TCP/IP, Parallel Library TCP/IP, and the NonStop
TCP/IPv6 subsystems, refer to the TCP/IP Configuration and Management Manual,
TCP/IP (Parallel Library) Configuration and Management Manual, and the TCP/IPv6
Configuration and Management Manual.
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
NonStop TCP/IP processes can interface to the network through the ServerNet LAN
Systems Access (SLSA) subsystem. The SLSA subsystem provides QIO-based driver
and interrupt handlers (DIHs) that allow NonStop TCP/IP processes to connect to a
LAN adapter. The SLSA subsystem is preconfigured and started during the systemload sequence.
For information about the SLSA subsystem, refer to the LAN Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
7 -3
Configuring Direct-Connect and Satellite-Connect
Lines
Ethernet 4 ServerNet Adapter (E4SA)
Ethernet 4 ServerNet Adapter (E4SA)
The E4SA is a double-high ServerNet adapter that supports four Ethernet interfaces
and communicates with multiple processors through dual ServerNet interfaces to the
ServerNet fabrics. Two E4SAs are used to connect a SWAN concentrator to a
processor. For information about E4SAs, refer to the LAN Configuration and
Management Manual.
Fast Ethernet ServerNet Adapter (FESA)
The FESA is a single-port adapter that provides connectivity between NonStop
S-series servers and Fast Ethernet 802.3u LANs. The data transfer rate is limited to 10
Mbps when the FESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the FESA is connected to a SWAN 2 concentrator. For
information about FESAs, refer to the LAN Configuration and Management Manual.
Gigabit Ethernet ServerNet Adapter (GESA)
The Gigabit Ethernet ServerNet adapter (GESA) is a single-port ServerNet adapter
that provides Gigabit connectivity between NonStop S-series systems and Ethernet
LANs. A GESA can be directly installed in slots 51 through 54 of an I/O enclosure and
slots 53 and 54 of a processor enclosure. The data transfer rate is limited to 10 Mbps
when the GESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the GESA is connected to a SWAN 2 concentrator. For
information about the GESA, refer to the LAN Configuration and Management Manual.
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA)
The Gigabit Ethernet 4-port ServerNet adapter (G4SA) is a multiport ServerNet
adapter that provides Gigabit connectivity between NonStop S-series systems and
Ethernet LANs. A G4SA can be directly installed in slots 1 through 5 of an I/O adapter
module (IOAM). Since there are two IOAMs in an IOAM enclosure, a total of 10 G4SAs
can be installed in an enclosure. The G4SA replaces the Ethernet 4 ServerNet adapter
(E4SA), Fast Ethernet ServerNet adapter (FESA), and the Gigabit Ethernet ServerNet
adapter (GESA). The G4SA is the only LAN adapter supported for the IOAM
enclosure, and it cannot be installed in a NonStop S-series enclosure. The data
transfer rate is limited to 10 Mbps when the G4SA is connected to a SWAN
concentrator, but a data transfer rate of 10/100 Mbps is possible when the G4SA is
connected to a SWAN 2 concentrator. For information about the G4SA, refer to the
LAN Configuration and Management Manual.
ServerNet Wide Area Network (SWAN) Concentrator
The SWAN concentrator is a communications device that provides WAN connections.
HP recommends that you configure your satellite-connect or direct-connect
line-handler process in the same processor pair as the SWAN concentrator.
Expand Configuration and Management Manual—523347-008
7 -4
Configuring Direct-Connect and Satellite-Connect
Lines
Topology Considerations
For information about the SWAN concentrator, refer to the WAN Subsystem
Configuration and Management Manual.
Topology Considerations
In a single-line path configuration, you configure one single-line direct-connect or
satellite-connect line-handler process for each path to an adjacent node. In a multiCPU path configuration, you configure multiple direct-connect or satellite-connect
line-handler processes, usually in separate processors, for each path to an adjacent
node. In a multi-line path configuration, you configure a path that consists of multiple
lines between two adjacent nodes.
In Figure 7-2, a single-line path is configured between node \A and node \B and
between node \B and node \A; a multi-CPU path that consists of two paths is
configured between node \A and node \C; and a multi-line path that consists of three
lines is configured between node \C and node \D.
Figure 7-2. Direct-Connect and Satellite-Connect Line-Handler Process Topology
Node \A
Node \B
CPU 0
CPU 0
LH
LH
CPU 1
LH
Single-Line Path
LH
CPU 2
LH
Multi-CPU Path
LH
CPU 0
LH
LH
CPU 1
CPU 1
LH
LH
Multiline Path
CPU 2
Node \C
Single-Line Path
CPU 2
Node \D
CDT 041.CDD
Expand Configuration and Management Manual—523347-008
7 -5
Configuring Direct-Connect and Satellite-Connect
Lines
Summary of Configuration Steps
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 7-2 for details), configuring and starting a single-line
direct-connect or satellite-connect line-handler process involves the following steps:
Step
Tool Used
Step 1: Find an Available WAN Line
SCF interface to the WAN
subsystem
Step 2: Create a Profile for the Line-Handler Process
SCF interface to the WAN
subsystem
Step 3: Create the Line-Handler Process
SCF interface to the WAN
subsystem
Step 4: Start the Line-Handler Process
SCF interface to the WAN
subsystem
Step 5: Start the Line
SCF interface to the Expand
subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure directconnect and satellite-connect line-handler processes; it is not meant to show the complete
syntax of the SCF commands described. Refer to the following manuals for more information:
•
•
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Step 1: Find an Available WAN Line
Note. The following procedure assumes that a SWAN concentrator has been installed,
configured, and started and has an available WAN line.
A direct-connect or satellite-connect line-handler process is configured to use an
available WAN line on a SWAN concentrator. You can use the WAN subsystem SCF
STATUS ADAPTER command to find an available WAN line on a SWAN concentrator
attached to your server. Available lines are indicated by the word FREE in the
command display.
Example 7-1 shows an example of a SCF STATUS ADAPTER command. In the
example, an available line is indicated on line 1 of communications line interface
processor (CLIP) 1 on the SWAN concentrator named S01. This information is shown
in boldface type.
Expand Configuration and Management Manual—523347-008
7 -6
Configuring Direct-Connect and Satellite-Connect
Lines
Step 2: Create a Profile for the Line-Handler Process
Example 7-1. SCF STATUS ADAPTER Command
-> status adapter $zzwan.#*, sub all
WAN Manager STATUS ADAPTER for ADAPTER
State........... STARTED
\NODEA.$ZZWAN.#S01
Number of clips. 3
Clip 1 status : CONFIGURED
Clip 2 status : CONFIGURED
Clip 3 status : CONFIGURED
WAN Manager STATUS SERVER for CLIP
\NODEA.$ZZWAN.#S01.1
State :......... STARTED
Path A..........: CONFIGURED
Path B..........: CONFIGURED
Number of lines. 2
Line............ 0
Line............ 1
: $X25A
: FREE
WAN Manager STATUS PATH for PATH
State :......... STARTED
\NODEA.$ZZWAN.#S01.1.A
MEDIA TYPE...... ETHERNET
MEDIA ADDRESS... %H000000000000
WAN Manager STATUS PATH for PATH
State :......... STARTED
\NODEA.$ZZWAN.#S01.1.B
MEDIA TYPE...... ETHERNET
MEDIA ADDRESS... %H000000000000
For more information about configuring and managing SWAN concentrators, refer to
the WAN Subsystem Configuration and Management Manual.
Step 2: Create a Profile for the Line-Handler
Process
You can create a profile for a single-line direct-connect line-handler process using the
PEXQSSWN profile. You can create a profile for a single-line satellite-connect
line-handler process using the PEXQSSAT profile. Both profiles are provided in the
$SYSTEM.SYSnn subvolume. You can also create a new profile from an existing
profile, or you can create your own profile. For complete information about profiles,
refer to the WAN Subsystem Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
7 -7
Configuring Direct-Connect and Satellite-Connect
Lines
ADD Profile Command
This subsection describes how to create a profile using PEXQSSWN and PEXQSSAT.
Note. Different profiles are provided for direct-connect and satellite-connect lines that are part
of a multi-line path; these profiles are described in Section 14, Configuring Multi-Line Paths.
ADD Profile Command
To create a profile from the PEXQSSWN or PEXQSSAT profile template, use the WAN
subsystem SCF ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference profile_name when you create a device for the line-handler process in
Step 3: Create the Line-Handler Process.
$SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSSWN is the disk filename of the profile provided for direct-connect
line-handler processes; PEXQSSAT is the disk file name of the profile provided for
satellite-connect line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSSWN
and PEXQSSAT profiles are listed in Profile Modifiers on page 7-13.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSSWN and PEXQSSAT profiles are described in Profile Modifiers on
page 7-13.
Examples
In the first example, a profile named SLHSAT is created for a single-line satelliteconnect line-handler process using the PEXQSSAT profile. The L4TIMEOUT modifier
is set to 1000 in the profile.
-> ADD PROFILE $ZZWAN.#SLHSAT, FILE $SYSTEM.SYS01.PEXQSSAT, &
14TIMEOUT 1000
Expand Configuration and Management Manual—523347-008
7 -8
Configuring Direct-Connect and Satellite-Connect
Lines
Step 3: Create the Line-Handler Process
In the next example, a profile named SLHDIR is created for a single-line direct-connect
line-handler process using the PEXQSSWN profile. The CLOCKSPEED_56000
modifier is set in the profile.
-> ADD PROFILE $ZZWAN.#SLHDIR, FILE $SYSTEM.SYS01.PEXQSSWN, &
CLOCKSPEED_56000
Step 3: Create the Line-Handler Process
You create a single-line direct-connect or satellite-connect line-handler process by
adding it as a device to the WAN subsystem.
Note. This section explains how to configure single-line direct-connect and satellite-connect
line-handler processes only. Creating direct-connect and satellite-connect lines that are part of
a multi-line path is explained in Section 14, Configuring Multi-Line Paths.
ADD DEVICE Command
To create a single-line direct-connect or satellite-connect line-handler process, use the
WAN subsystem SCF ADD DEVICE command. The command syntax is as follows:
ADD
,
,
,
,
,
.
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,5 )
RSIZE rsize
ADAPTER concname
CLIP clipnum
LINE linenum
PATH { A | B }
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
is the device name of the Expand line-handler process you want to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for this Expand line-handler process in Step
2: Create a Profile for the Line-Handler Process.
Expand Configuration and Management Manual—523347-008
7 -9
Configuring Direct-Connect and Satellite-Connect
Lines
ADD DEVICE Command
CPU cpunumber
indicates the processor where this Expand line-handler process will normally
execute. HP recommends that you specify the same processor as that configured
for the preferred NonStop TCP/IP process used by the SWAN concentrator
specified by concname.
ALTCPU altcpunumber
indicates the processor where the backup Expand line-handler process will
normally execute. HP recommends that you specify the same processor as that
configured for the alternate NonStop TCP/IP process used by the SWAN
concentrator specified by concname.
TYPE (63,5)
is the device type and subtype for this Expand line-handler process. The device
type is always 63 for Expand line-handler processes. The subtype is 5 for both
single-line direct-connect and satellite-connect line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ADAPTER concname
is the SWAN concentrator you selected for use by this Expand line-handler
process in Step 1: Find an Available WAN Line on page 7-6.
CLIP clipnum
is the CLIP number on the SWAN concentrator specified by concname that
contains an available WAN line. Refer to Step 1: Find an Available WAN Line on
page 7-6 for information about identifying CLIP numbers.Valid values are 1, 2, or 3.
LINE linenum
is the number of an available WAN line on the CLIP specified by clipnum. Refer
to Step 1: Find an Available WAN Line on page 7-6 for information about identifying
line numbers. Valid values are 0 or 1.
PATH { A | B }
is the path (A or B) on the CLIP specified by clipnum that you prefer. The path
must be configured.
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 to 254) of the system
connected to the other end of the line. If you do not specify the NEXTSYS modifier,
it defaults to an invalid value (255) and an operator message occurs during the
Expand Configuration and Management Manual—523347-008
7- 10
Configuring Direct-Connect and Satellite-Connect
Lines
Considerations
initialization of the Expand line-handler process. The path will not be operational
until you alter NEXTSYS to a valid value using either the WAN subsystem SCF
ALTER DEVICE command or the Expand subsystem SCF ALTER PATH
command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this Expand line-handler process.
Modifier names in the PEXQSSWN and PEXQSSAT profiles are listed in Profile
Modifiers on page 7-13.
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXQSSWN and
PEXQSSAT profiles are described in Profile Modifiers on page 7-13.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Examples
In the first example, a device named $DIR6 is created for a single-line direct-connect
line-handler process that uses a SWAN concentrator named S01. The
PATHBLOCKBYTES modifier enables the multipacket frame feature.
-> ADD DEVICE $ZZWAN.#DIR6, PROFILE SLHTER, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,5), &
RSIZE 0, PATHTF 3, CLIP 2, LINE 0, ADAPTER S01, PATH A, &
NEXTSYS 12, PATHBLOCKBYTES 1024
In the next example, a device named $SAT1 is created for a single-line satelliteconnect line-handler process that uses a SWAN concentrator named S02.
-> ADD DEVICE $ZZWAN.#SAT1, PROFILE SLHSAT, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,5), &
RSIZE 0, PATHTF 3, CLIP 2, LINE 0, ADAPTER S02, PATH A, &
NEXTSYS 14
Expand Configuration and Management Manual—523347-008
7- 11
Configuring Direct-Connect and Satellite-Connect
Lines
Step 4: Start the Line-Handler Process
In the last example, a device named $DIR2 is created for a direct-connect line-handler
process that uses a SWAN concentrator named S02. $DIR2 is also a member of a
multi-CPU path. The SUPERPATH_ON and L4EXTPACKETS_ON modifiers are
required for line-handler processes that are part of a multi-CPU path. The
L4CONGCTRL_ON modifier is recommended for Expand line-handler processes that
are part of a multi-CPU path.
-> ADD DEVICE $ZZWAN.#DIR2, PROFILE SLHTER, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,5), RSIZE 0, &
PATHTF 3, CLIP 2, LINE 0, ADAPTER S02, PATH A, NEXTSYS 13, &
14EXTPACKETS_ON, 14CONGCTRL_ON, SUPERPATH_ON
Step 4: Start the Line-Handler Process
To start a single-line direct-connect or satellite-connect line-handler process, use the
WAN subsystem SCF START DEVICE command. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the direct-connect or
satellite-connect Expand line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Step 5: Start the Line
To start the path and line functions of a single-line direct-connect or satellite-connect
line-handler process, use the Expand subsystem SCF START LINE command. The
command syntax is as follows:
START LINE $device_name
device_name
is the device name of the direct-connect or satellite-connect Expand line-handler
process.
The successful completion of this command leaves the line in the STARTED state.
Expand Configuration and Management Manual—523347-008
7- 12
Configuring Direct-Connect and Satellite-Connect
Lines
Profile Modifiers
Profile Modifiers
This subsection lists the modifiers provided for configuring special features. It also
describes default values and value ranges for the modifiers contained in the
PEXQSSWN and PEXQSSAT profiles.
Note. Different profiles are provided for direct-connect and satellite-connect lines that are part
of a multi-line path; these profiles are described in Section 14, Configuring Multi-Line Paths.
Modifiers for Special Features
The following modifiers are provided in the PEXQSSWN and PEXQPSAT profiles to
enable you to configure special features:
•
•
•
•
PATHBLOCKBYTES modifier for the multipacket frame feature
PATHPACKETBYTES modifier for the variable packet size feature
L4CONGCTRL_ON modifier for the congestion control feature
SUPERPATH_ON modifier for the Expand multi-CPU feature
For configuration considerations for these features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of these
features, refer to Section 3, Planning a Network Design.
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
PEXQSSWN and PEXQSSAT Modifiers
The disk file $SYSTEM.SYSnn.PEXQSSWN defines modifiers for single-line directconnect line-handler processes. The disk file $SYSTEM.SYSnn.PEXQSSAT defines
modifiers for single-line satellite-connect line-handler processes.
Table 7-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Table 7-1. PEXQSSWN and PEXQSSAT Modifiers (page 1 of 3)
Modifier
Default Value
Range of Values
CLBDWNLOADRETRIES
3
2 to 255
CLBDWNLOADTIMR
30 seconds
30 secs to 5:27:67 minutes
CLOCKMODE_DCE
3
CLOCKMODE_DTE
CLOCKSPEED_600
CLOCKSPEED_1200
Expand Configuration and Management Manual—523347-008
7- 13
Configuring Direct-Connect and Satellite-Connect
Lines
PEXQSSWN and PEXQSSAT Modifiers
Table 7-1. PEXQSSWN and PEXQSSAT Modifiers (page 2 of 3)
Modifier
Default Value
Range of Values
CLOCKSPEED_2400
CLOCKSPEED_4800
CLOCKSPEED_9600
CLOCKSPEED_19200
3
CLOCKSPEED_38400
CLOCKSPEED_56000
CLOCKSPEED_115200
COMPRESS_OFF
COMPRESS_ON
3
DELAY
10
0 to 511
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
DSRTIMER
1 sec
1 sec to 5:27:67 minutes
EXTMEMSIZE
2048
0 through 32767
FLAGFILL_OFF
FLAGFILL_ON
3
FRAMESIZE
132
64 through 2047
INSPECT
INTERFACE_RS232
3
INTERFACE_RS422
L2DISCARDONRESET_OFF
L2DISCARDONRESET_ON
3
L2RETRIES
10
1 through 255
L2TIMEOUT
100 (direct-connect)
200 (satellite-connect)
20 to 32767
L4CONGCTRL_OFF
3
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
NEXTSYS1
255
0 to 254
Expand Configuration and Management Manual—523347-008
7- 14
Configuring Direct-Connect and Satellite-Connect
Lines
PEXQSSWN and PEXQSSAT Modifiers
Table 7-1. PEXQSSWN and PEXQSSAT Modifiers (page 3 of 3)
Modifier
Default Value
Range of Values
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0
0 through 186
PROGRAM
$SYSTEM.CSSnn.
C1097P00 (directconnect)
$SYSTEM.CSSnn.
C1098P00 (satelliteconnect)
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60 seconds
0 to 77600 (12hrs)
RXWINDOW
7
2 through 15
SPEED
0
0 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
3
SUPERPATH_ON
TXWINDOW
7 (direct-connect)
18 (satellite-connect)
2 through 61 (all lines)
1. This is a required modifier. The default value is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
7- 15
Configuring Direct-Connect and Satellite-Connect
Lines
PEXQSSWN and PEXQSSAT Modifiers
Expand Configuration and Management Manual—523347-008
7- 16
8
Configuring Expand-Over-IP Lines
The Expand-over-IP line-handler process provides connectivity to an Internet Protocol
(IP) network. The Expand-over-IP line-handler process uses the services of the
NonStop TCP/IP subsystem to provide Expand-over-IP connections.
Effective with the G06.20 RVU, NonStop TCP/IPv6 supports IP version 6 (IPv6)
communications. The major change in IPv6 is that it supports a larger, 128-bit (16-byte)
IP address that helps to address the growing number of machines and devices on the
Internet.
NonStop TCP/IPv6 includes all the features of Parallel Library TCP/IP (TCP/IP/PL)
along with support of (optional) IPv6 communications and, with G06.22, logical network
partitioning (LNP).
You cannot run NonStop TCP/IPv6 and Parallel Library TCP/IP on the same system,
however you can run NonStop TCP/IP and NonStop TCP/IPv6 on the same system.
For more information about NonStop TCP/IP, Parallel Library TCP/IP, and NonStop
TCP/IPv6, refer to the TCP/IP Configuration and Management Manual, the TCP/IP
(Parallel Library) Configuration and Management Manual, and the TCP/IPv6
Configuration and Management Manual.
An Expand-over-IP line-handler process can be configured as a single line, as part of a
multi-line path, or as part of multi-CPU path. This section explains how to configure an
Expand-over-IP line-handler process as a single-line or as part of a multi-CPU path.
Configuring Expand-over-IP lines that are part of a multi-line path is explained in
Section 14, Configuring Multi-Line Paths.
Expand Configuration and Management Manual—523347-008
8 -1
Required Hardware and Software
Configuring Expand-Over-IP Lines
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-IP line-handler process to provide Expand-over-IP connectivity.
Figure 8-1 shows the relationship between the Expand subsystem, the NonStop
TCP/IP subsystem and the LAN adapter. The TCP/IP process in this configuration can
be either a NonStop TCP/IP, Parallel Library TCP/IP (TCPSAM process) or NonStop
TCP/IPv6 (TCP6SAM process). (However, in the case of Parallel Library TCP/IP and
NonStop TCP/IPv6, the architecture is somewhat different in that the TCPSAM and
TCP6SAM processes are actually not providing the connectivity. For simplicity, they
are shown here as interchangeable with the NonStop TCP/IP process for Expand
purposes. For more information about the architectures of these two subsystems, see
the TCP/IP (Parallel Library) Configuration and Management Manual and the TCP/IPv6
Configuration and Management Manual.)
Figure 8-1. Expand-Over-IP Connectivity Components with a LAN Adapter
Processor
QIO Shared
Memory
Segment
Expand-over-IP
Line-Handler
Process
TCP/IP Library
LAN Driver and Interrupt Handlers
(DIHs)
Y-Fabric
X-Fabric
LAN Adapter
VST006.vsd
Expand Configuration and Management Manual—523347-008
8 -2
QIO Subsystem
Configuring Expand-Over-IP Lines
Figure 8-2 illustrates the required components when an ATM 3 ServerNet adapter
(ATM3SA) is used to provide connectivity to an IP network. In this configuration, the
TCP/IP process can only be NonStop TCP/IP; Parallel Library TCP/IP and NonStop
TCP/IPv6 do not support ATM communications.
Figure 8-2. Expand-Over-IP Connectivity Components with ATM3SA
Processor
QIO
Shared
Memory
Segment
Expand-over-IP
Line-Handler
Process
TCP/IP
Process
ATM Subsystem
Y-Fabric
X-Fabric
ATM3SA
CDT 058.CDD
QIO Subsystem
QIO is a mechanism for transferring data between processes through a shared
memory segment. The QIO subsystem is preconfigured and started during the system
load sequence. The QIO subsystem must be started and running before Expand
line-handler processes can be started.
Refer to Shared Memory Area for QIO on page 18-48 for information on QIO
enhancements that enable you to have more control over certain aspects of memory
management. For information about the QIO subsystem, refer to the QIO Configuration
and Management Manual.
Expand Configuration and Management Manual—523347-008
8 -3
Configuring Expand-Over-IP Lines
NonStop TCP/IP Process
NonStop TCP/IP Process
The Expand-over-IP line-handler process uses the services of a NonStop TCP/IP
process to provide TCP/IP connectivity. The NonStop TCP/IP process and SUBNET
associated with the Expand-over-IP line-handler process must be defined and started
before the Expand-over-IP line-handler process can be started. It must be configured
in the same processor pair as the Expand-over-IP line-handler process.
For information about configuring and managing NonStop TCP/IP processes, refer to
the TCP/IP Configuration and Management Manual.
Parallel Library TCP/IP and NonStop TCP/IPv6 Processes
Parallel Library TCP/IP and NonStop TCP/IPv6 can also provide TCP/IP connectivity
for the Expand-over-IP line-handler process. NonStop TCP/IPv6 can optionally provide
support for IP version 6 communications and also has a feature called logical network
partitioning (LNP) that allows you to configure the line-handler process such that it only
has access to a configured set of IP addresses. (In both Parallel Library TCP/IP and
NonStop TCP/IPv6 without LNP, the Expand line-handler process has access to all the
IP addresses in the subsystem.) Both products provide performance enhancements
and eliminate the need to configure the line-handler processes in the same CPU pair
as the TCP/IP processes. In addition, both Parallel Library TCP/IP and NonStop
TCP/IPv6 provide Ethernet failover capabilities. (Parallel Library TCP/IP and NonStop
TCP/IPv6 only support Ethernet adapters.)
The line handler supports the 128-bit addressing scheme used in IPv6
communications, as well as the 32-bit addresses used by IPv4.
Redundancy in Ethernet Adapters
Redundancy in Ethernet adapters and IP network routes can be applied by multi-line
Expand-over-IP paths and multi-CPU paths, where the member paths are Expandover-IP. These configurations offer multiple, parallel connections between a NonStop
system and one of its neighbors. With these configurations, there is potentially greater
bandwidth and fault tolerance. For the full benefit to exist, however, all elements,
including the network itself, must have redundancy.
The decision of which adapter/path to apply for a particular Expand connection in
conventional NonStop TCP/IP and in LNP-configured NonStop TCP/IPv6 is made
explicitly by how you configure the adapters, NonStop TCP/IP processes, and lines.
This selection is independent of the external network. The adapters and lines will be
applied in parallel, but if there is no redundancy in the network to which they connect,
the effectiveness of the parallelism is considerably reduced. In these cases, the faulttolerance decisions made in Expand for multi-line IP paths may be disruptive rather
than helpful.
Parallel Library TCP/IP and NonStop TCP/IPv6 configured without LNP make a
dynamic choice of which adapter/line to employ, among any configured redundant
assortment, based on the destination address of the IP connection and the best route
Expand Configuration and Management Manual—523347-008
8 -4
Configuring Expand-Over-IP Lines
Local Area Network (LAN) Driver and Interrupt
Handlers (DIHs)
to that destination. Unless network redundancy is provided implicitly in the destination
addresses, the same adapter/line may be used for all connections to the same
neighbor. Both Parallel Library TCP/IP and NonStop TCP/IPv6 (in either LNP or nonLNP mode) can be configured with a redundancy feature at the adapter level called
Ethernet failover. This feature allows you to configure two network interfaces (IP
addresses and their associated physical interfaces on the Ethernet adapter) as a
failover pair. Each network interface in this failover pair provides full, independent
network connectivity in normal conditions and provides backup connectivity for its
brother during a failure. If one member of the failover pair fails, the Parallel Library
TCP/IP or NonStop TCP/IPv6 subsystem automatically routes network traffic destined
for the failed interface over its failover brother.
For information about configuring Ethernet failover in Parallel Library TCP/IP, see the
TCP/IP (Parallel Library) Configuration and Management Manual. For information
about configuring Ethernet failover in NonStop TCP/IPv6, see the TCP/IPv6
Configuration and Management Manual.
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
NonStop TCP/IP processes can interface to an IP network through the ServerNet LAN
Systems Access (SLSA) subsystem. The SLSA subsystem provides QIO-based driver
and interrupt handlers (DIHs) that allow NonStop TCP/IP processes to connect to a
LAN adapter. The SLSA subsystem is preconfigured and is started during the systemload sequence.
For information about the SLSA subsystem, refer to the LAN Configuration and
Management Manual.
Asynchronous Transfer Mode (ATM) Subsystem
NonStop TCP/IP processes may also interface to an IP network through the
Asynchronous Transfer Mode (ATM) subsystem. The ATM subsystem provides
software that allows NonStop TCP/IP processes to connect to an ATM ServerNet
adapter (ATM3SA). You must install the ATM3SA and configure and start the ATM
subsystem before you can start an Expand-over-IP line-handler process that uses this
connection method.
For information about the ATM subsystem, refer to the ATM Configuration and
Management Manual.
E4SA, FESA, GESA, G4SA and ATM3SA
You can use either an E4SA, FESA, GESA, G4SA, or an ATM3SA to provide
connectivity to an IP network.
The E4SA is a double-high ServerNet adapter that supports four Ethernet interfaces
and communicates with multiple processors through its dual ServerNet interfaces to
the ServerNet fabrics. Two E4SAs are used to connect a SWAN concentrator to a
processor.
Expand Configuration and Management Manual—523347-008
8 -5
Configuring Expand-Over-IP Lines
Topology Considerations
The FESA is a single-port adapter that provides connectivity between NonStop
S-series servers and Fast Ethernet 802.3u LANs. The data transfer rate is limited to 10
Mbps when the FESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the FESA is connected to a SWAN 2 concentrator.
The Gigabit Ethernet ServerNet adapter (GESA) is a single-port ServerNet adapter
that provides Gigabit connectivity between NonStop S-series systems and Ethernet
LANs. A GESA can be directly installed in slots 51 through 54 of an I/O enclosure and
slots 53 and 54 of a processor enclosure. The data transfer rate is limited to 10 Mbps
when the GESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the GESA is connected to a SWAN 2 concentrator.
The Gigabit Ethernet 4-port ServerNet adapter (G4SA) is a multiport ServerNet
adapter that provides Gigabit connectivity between NonStop S-series systems and
Ethernet LANs. A G4SA can be directly installed in slots 1 through 5 of an I/O adapter
module (IOAM). Since there are two IOAMs in an IOAM enclosure, a total of 10 G4SAs
can be installed in an enclosure. The G4SA replaces the Ethernet 4 ServerNet adapter
(E4SA), Fast Ethernet ServerNet adapter (FESA), and the Gigabit Ethernet ServerNet
adapter (GESA). The G4SA is the only LAN adapter supported for the IOAM
enclosure, and it cannot be installed in a NonStop S-series enclosure. The data
transfer rate is limited to 10 Mbps when the G4SA is connected to a SWAN
concentrator, but a data transfer rate of 10/100 Mbps is possible when the G4SA is
connected to a SWAN 2 concentrator.
The ATM3SA provides one bidirectional full-duplex ATM OC3 port for connections to
the User-Network Interface (UNI) through its dual ServerNet interfaces to the
ServerNet fabrics. The UNI is an interface point between ATM end users and a private
ATM switch, or between a private ATM switch and the public carrier ATM network.
For information about the E4SA, FESA, GESA, and G4SA, refer to the LAN
Configuration and Management Manual. For information about the ATM3SA, refer to
the ATM Configuration and Management Manual.
Topology Considerations
In a single-line path configuration, you configure one Expand-over-IP line-handler
process for each path to an adjacent node. In a multi-CPU path configuration, you
configure multiple Expand-over-IP line-handler processes, usually in separate
processors, for each path to an adjacent node. In a multi-line path configuration, you
configure a path that consists of multiple lines between two adjacent nodes.
In Figure 8-3, a single-line path is configured between node \A and node \B; a multiCPU path that consists of two paths is configured between node \A and node \C; and a
multi-line path that consists of three lines is configured between node \C and node \D.
Expand Configuration and Management Manual—523347-008
8 -6
Topology Considerations
Configuring Expand-Over-IP Lines
Figure 8-3. Expand-Over-IP Line-Handler Process Topology
Node \B
Node \A
CPU 0
CPU 0
LH
CPU 1
CPU 2
LH
IP Network
LH
Single-Line Path
LH
IP Network
Multi-CPU Path
LH
CPU 1
LH
CPU 2
LH
IP Network
CPU 3
Node \C
LH
CPU 0
Multiline Path
Node \D
Expand Configuration and Management Manual—523347-008
8 -7
CDT 042.CDD
Configuring Expand-Over-IP Lines
Summary of Configuration Steps
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 8-2 for details), configuring and starting a single-line
Expand-over-IP line-handler process involves the following steps. Use Steps A or B
depending on which version of TCP/IP you want to use.
Step
Tool Used
Step 1 (A): Select a Process and SUBNET for NonStop
TCP/IP Use
SCF interface to the
NonStop TCP/IP
subsystem
Step 1 (B): Select a TCPSAM Process and SUBNET for
Parallel Library TCP/IP Use
SCF interface to the
Parallel Library TCP/IP
subsystem
Step 1 (C): Select a Process and SUBNET for NonStop
TCP/IPv6 Use
SCF interface to the
NonStop TCP/IPv6
subsystem
Step 2 (A): Identify an Available UDP Port Number
SCF interface to the
NonStop TCP/IP
subsystem
Step 2 (B): Identify an Available UDP Port Number for Parallel
Library TCP/IP Use
SCF interface to the
Parallel Library TCP/IP
subsystem
Step 2 (C): Identify an Available UDP Port Number for
TCP/IPv6 Use
SCF interface to the
NonStop TCP/IPv6
subsystem
Step 3: Create a Profile for the Line-Handler Process
SCF interface to the WAN
subsystem
Step 4: Create the Line-Handler Process
SCF interface to the WAN
subsystem
Step 5: Start the Line-Handler Process
SCF interface to the WAN
subsystem
Step 6: Start the Line
SCF interface to the
Expand subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure
Expand-over-IP line-handler processes; it is not meant to show the complete syntax of SCF
commands described. Refer to the following for more information:
•
•
•
•
•
TCP/IP Configuration and Management Manual
TCP/IP (Parallel Library) Configuration and Management Manual
TCP/IPv6 Configuration and Management Manual
WAN Subsystem Configuration and Management Manual
Section 15, Subsystem Control Facility (SCF) Commands
Expand Configuration and Management Manual—523347-008
8 -8
Step 1 (A): Select a Process and SUBNET for
NonStop TCP/IP Use
Configuring Expand-Over-IP Lines
Step 1 (A): Select a Process and SUBNET for
NonStop TCP/IP Use
Note. The following instructions assume that a NonStop TCP/IP process has already been
created. For information about creating NonStop TCP/IP processes, refer to the TCP/IP
Configuration and Management Manual.
A NonStop TCP/IP SUBNET associates a NonStop TCP/IP process with a connection
to a network and an IP address.
Select a NonStop TCP/IP Process
The NonStop TCP/IP process provides access to the NonStop TCP/IP environment. In
configuring Expand-over-IP for this environment, you will be using the name of a
NonStop TCP/IP process for the ASSOCIATEDEV modifier in Step 4: Create the LineHandler Process.
To obtain a list of running NonStop TCP/IP processes, issue the following command:
> LISTDEV TCPIP
The SCF LISTDEV command lists all the TCP/IP processes. A program name in the
SCF LISTDEV display of TCPIP means that it's a NonStop TCP/IP process.
Example 8-3 shows a sample result of the SCF LISTDEV TCPIP command.
Example 8-1. SCF LISTDEV TCPIP Command
1
2
3
4
5
7
8
SCF - T9082G02 - (05AUT99) (26JUL99) - 12/22/1999 14:52:00 System \NODEA
Copyright Hewlett-Packard Company
LDev
107
154
158
Name
$ZB01A
$ZTC0
$ZB019
PPID
0,285
0,299
1,293
BPID
1,287
1,286
0,302
Type
(48,0)
(48,0)
(48,0)
RSize
32000
32000
32000
Pri
200
200
200
Program
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$SYSTEM.3.TCPIP
In the above example, the processes $ZB01A, $ZTCO, and $ZB019 are NonStop
TCP/IP processes. For the rest of this procedure, we will use $ZB01A as our NonStop
TCP/IP process.
Select a SUBNET for NonStop TCP/IP
You can use the SCF INFO SUBNET command to determine if a SUBNET has been
configured for the NonStop TCP/IP process you plan to associate with the Expandover-IP line-handler process. Example 8-2 shows an example of an SCF INFO
SUBNET command for a NonStop TCP/IP process named $ZTC01.
Expand Configuration and Management Manual—523347-008
8 -9
Creating an Ethernet SUBNET or ATM SUBNET
Configuring Expand-Over-IP Lines
Example 8-2. SCF INFO SUBNET Command
2-> INFO SUBNET $ZB01A.#*
TCPIP Info SUBNET \NODEA.$ZB01A.*
Name
Devicename
#LOOP0
#SN1
#SN2
\NODEB.$NOIOP
\NODEA.$LAN01
\NODEA.$AM1
*IPADDRESS
127.0.0.1
172.16.35.15
172.16.192.20
TYPE
*SUBNETMASK
SuName
LOOP-BACK %HFF000000
ETHERNET %HFFFFFF00
ATM
%HFFFFFF00
QIO *R
OFF N
ON N
ON N
SUBNET names are shown in the Name field, the type of the SUBNET configured is
shown in the Type field, and the IP address assigned to the SUBNET is shown in the
IPADDRESS field. As shown in Example 8-2, there is one Ethernet SUBNET (#SN1)
and one ATM SUBNET (#SN2) configured.
You must specify the IP address associated with an Ethernet or ATM SUBNET when
you define the Expand-over-IP line-handler process in Step 4: Create the Line-Handler
Process.
Creating an Ethernet SUBNET or ATM SUBNET
If an Ethernet or ATM SUBNET does not already exist, you can create one using the
SCF ADD SUBNET command. The SCF ADD SUBNET command shown as follows
defines an Ethernet SUBNET named #SN1 for a NonStop TCP/IP process named
$ZTC01. The DEVICENAME modifier specifies the name of the logical interface (LIF)
that is used to communicate with the physical interface (PIF) on an E4SA connected to
the system.
-> ADD SUBNET $ZTC01.#SN1, TYPE ETHERNET, &
DEVICENAME $ZZLAN.LAN0, IPADDRESS 123.45.67.89
The SCF ADD SUBNET command shown as follows defines an ATM SUBNET named
#SN2 for a NonStop TCP/IP process named $ZTC01. The DEVICENAME modifier
specifies the name of an ATM line on an ATM3SA connected to the system.
-> ADD SUBNET $ZTC01.#SN2, TYPE ATM, DEVICENAME $AM1, &
IPADDRESS 172.16.192.200, ARPSERVER ON, ATMSEL 1
After the SUBNET is defined, it must be started using the SCF START SUBNET
command. The SCF START SUBNET command shown as follows starts the SUBNET
named #SN1:
-> START SUBNET $ZTC01.#SN1
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination IP address must be specified when
the local Expand-over-IP line-handler process is defined.
For more information about creating SUBNETs, refer to the TCP/IP Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
8- 10
Step 1 (B): Select a TCPSAM Process and SUBNET
for Parallel Library TCP/IP Use
Configuring Expand-Over-IP Lines
Step 1 (B): Select a TCPSAM Process and
SUBNET for Parallel Library TCP/IP Use
Note. The following instructions assume that a Parallel Library TCP/IP environment has
already been started. For information about starting a Parallel Library TCP/IP environment,
refer to the TCP/IP (Parallel Library) Configuration and Management Manual.
Step 1 (B) is for use with the Parallel Library version of TCP/IP only.
The Parallel Library version of TCP/IP only supports SUBNETs of type Ethernet.
A Parallel Library TCP/IP SUBNET associates the Parallel Library TCP/IP environment
with a connection to a network and an IP address.
Select a TCPSAM Process
The TCP/IP socket access method (TCPSAM) is the process that provides access to
the Parallel Library TCP/IP environment. In configuring Expand-over-IP for this
environment, you will be using the name of a TCPSAM process for the
ASSOCIATEDEV modifier in Step 4: Create the Line-Handler Process.
To obtain a list of running TCPSAM processes, issue the following command:
> LISTDEV TCPIP
The SCF LISTDEV command lists all the TCP/IP processes. A program name in the
SCF LISTDEV display of TCPIP means that it's a conventional NonStop TCP/IP
process whereas a program name of TCPSAM means it's a Parallel Library TCP/IP
process. Example 8-3 shows a sample result of the SCF LISTDEV TCPIP command.
Example 8-3. SCF LISTDEV TCPIP Command
1
2
3
4
5
6
7
8
9
SCF - T9082G02 - (05AUT99) (26JUL99) - 12/22/1999 14:52:00 System \NODEA
Copyright Hewlett-Packard Company
LDev
107
141
154
158
190
Name
$ZB01A
$ZSAM1
$ZTC0
$ZB019
$ZSAM2
PPID
0,285
3,269
0,299
1,293
1,310
BPID
1,287
0,0
1,286
0,302
0.0
Type
(48,0)
(48,0)
(48,0)
(48,0)
(48,0)
RSize
32000
57344
32000
32000
57344
Pri
200
201
200
200
201
Program
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$DATA01.GUAR.TCPSAM
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$DATA01.GUAR.TCPSAM
In the above example, the processes $ZSAM1 and $ZSAM2 are TCPSAM processes.
For the rest of this procedure, we will use $ZSAM1 as our TCPSAM process.
Expand Configuration and Management Manual—523347-008
8- 11
Select a SUBNET for Parallel Library TCP/IP
Configuring Expand-Over-IP Lines
Select a SUBNET for Parallel Library TCP/IP
You can use the SCF INFO SUBNET command to determine if a SUBNET has been
configured for the TCPSAM process you plan to associate with the Expand-over-IP
line-handler process. Example 8-4 shows an example of an SCF INFO SUBNET
command for a process named $ZSAM1.
Example 8-4. SCF INFO SUBNET Command for TCPSAM
2-> info subnet $zsam1.*
TCPIP Info SUBNET \NODEC.$ZSAM1.*
Name
LOOP0
SN1
Devicename
\NOSYS.$NOIOP
\NODEC.$LAN01
*IPADDRESS
127.0.0.1
172.16.35.15
TYPE
*SUBNETMASK
LOOP-BACK %HFF000000
ETHERNET %HFFFFFF00
SuName
QIO *R
OFF N
ON
SUBNET names are shown in the Name field, the type of the SUBNET configured is
shown in the Type field, and the IP address assigned to the SUBNET is shown in the
IPADDRESS field. As shown in Example 8-2, there is one Ethernet SUBNET (SN1)
configured.
You must specify the IP address associated with an Ethernet SUBNET when you
define the Expand-over-IP line-handler process in Step 4: Create the Line-Handler
Process.
Creating an Ethernet SUBNET
If an Ethernet SUBNET does not already exist, you can create one using the SCF ADD
SUBNET command. The SCF ADD SUBNET command shown in the following
example defines an Ethernet SUBNET named SN1 for the Parallel TCP/IP
environment. The DEVICENAME modifier specifies the name of the logical interface
(LIF) that is used to communicate with the physical interface (PIF) on an E4SA
connected to the system.
-> ADD SUBNET $ZZTCP.*.SN1, TYPE ETHERNET, &
DEVICENAME $ZZLAN.LAN02, IPADDRESS 123.45.67.89,&
SUBNETMASK %HFFFFFF00
After the SUBNET is defined, it must be started using the SCF START SUBNET
command. The SCF START SUBNET command shown in the following example starts
the SUBNET named SN1:
-> START SUBNET $ZZTCP.*.SN1
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination IP address must be specified when
the local Expand-over-IP line-handler process is defined.
For more information about creating SUBNETs, refer to the TCP/IP (Parallel Library)
Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
8- 12
Configuring Expand-Over-IP Lines
Step 1 (C): Select a Process and SUBNET for
NonStop TCP/IPv6 Use
Step 1 (C): Select a Process and SUBNET for
NonStop TCP/IPv6 Use
Note. The following instructions assume that a NonStop TCP/IPv6 environment has already
been started. For information about starting a NonStop TCP/IPv6 environment, refer to the
TCP/IPv6 Configuration and Management Manual.
Step 1 (C) is for use with NonStop TCP/IPv6 only.
Select a SUBNET for NonStop TCP/IPv6 Use
NonStop TCP/IPv6 only supports SUBNETs of type Ethernet. A NonStop TCP/IPv6
SUBNET associates the NonStop TCP/IPv6 environment with a connection to a
network and an IP address.
To obtain a list of running IPv6 and IPv6 SUBNETs, issue the following SCF command:
> INFO SUBNET $ZZTCP.*, DETAIL
Note. For NonStop TCP/IPv6, we use the SCF INFO SUBNET command to the manager
process ($ZZTCP) for the example because it shows IPv6 address whereas the SCF INFO
SUBNET command to the TCP6SAM process shows only IPv4 addresses. If you are using
NonStop TCP/IPv6 in INET mode (IPv4 addresses only), you can issue the INFO SUBNET
command to the TCP6SAM process just like in the procedure for Parallel Library TCP/IP.
Example 8-5 shows a sample result of the SCF INFO SUBNET, DETAIL command.
Expand Configuration and Management Manual—523347-008
8- 13
Configuring Expand-Over-IP Lines
Select a SUBNET for NonStop TCP/IPv6 Use
Example 8-5. SCF INFO SUBNET, DETAIL Command
TCPIPV6 Detailed Info SUBNET \NODEA.$ZZTCP.#ZPTMF.*
AF_INET:
Name
Devicename
*IPADDRESS/DST_IPADDR TYPE
*SUBNETMASK
SN116
\NODEA.FEF0A
172.10.188.140
ETHERNET %HFFFFFF00
Trace Status ........ OFF
Trace Filename ......
Interface MTU ....... 1500
---Multicast Groups-----State--224.0.0.1
STARTED
LNP... $ZB01A
Index... 1
LOOP0
127.0.0.1
LOOP
%HFF000000
Trace Status ........ OFF
Trace Filename ......
Interface MTU ....... 32768
---Multicast Groups-----State--224.0.0.1
STARTED
LNP... $ZSAM1
Index... 1
AF_INET6:
Name
Devicename
LinkLevelAddress
SN117
\NODEA.FEF0A
fe80::a00:8eff:fe02:46e
*IPV6MTU................... 1500
*IPV6HOPLIMIT.............. 64
*IPV6REACHABLETIME......... 30000 ms
*IPV6RETRANSMITIMER........ 1000 ms
*IPV6DADRETRIES............ 1
*IPV6NUD................... ON
*IPV6RAENABLE.............. ON
LNP... DEFAULT
Index... 0
IPV6PREFIX........ 3ffe:1200:188:2::/64
IPV6PREFIX........ 3ffe:1200:188:1::/64
IPV6ADDRESS....... 3ffe:1200:188:1:a00:8eff:fe02:46e
Creation Type. RA PREFIX
IPV6ADDRESS....... 3ffe:1200:188:2:a00:8eff:fe02:46e
Creation Type. RA PREFIX
MULTICASTADDRESS.. ff02::1:ff02:46e
MULTICASTADDRESS.. ff02::1
*R LNP
N 0
N
0
TYPE
LNP
ETHERNET 0
SUBNET names are shown in the Name field, the type of the SUBNET configured is
shown in the Type field, and the IP address assigned to the SUBNET is shown in the
IPADDRESS field.
You must specify the IP address associated with an Ethernet SUBNET when you
define the SRCIPADDR modifier for the Expand-over-IP line-handler process in Step 4:
Create the Line-Handler Process. If the NonStop TCP/IPv6 environment is set up to
use logical network partitioning (see Internet Protocol (IP) Networks on page 3-4), as
the environment shown in this example is, the IP address you select is accessible only
to the TCP6SAM processes associated with it. (If the NonStop TCP/IPv6 environment
is not set up with LNP, all TCP6SAM processes have access to all IP addresses in the
NonStop TCP/IPv6 subsystem.)
In this example, we use SUBNET SN116 and its IP address, 172.10.188.140. Note that
the TCP6SAM process shown in the LNP field is $ZSAM1. That means $ZSAM1 is the
only TCP6SAM process that has access to the LNP that SUBNET SN116 and its IP
address 172.10.188.140 form. Note also that SN117 shows DEFAULT in the LNP field.
Expand Configuration and Management Manual—523347-008
8- 14
Select a TCP6SAM Process
Configuring Expand-Over-IP Lines
If you want to use the default LNP, select a SUBNET that has DEFAULT in the LNP
field.
Select a TCP6SAM Process
The TCP/IP socket access method (TCP6SAM) is the process that provides access to
the NonStop TCP/IPv6 environment. In configuring Expand-over-IP for this
environment, you use the name of a TCP6SAM process for the ASSOCIATEDEV
modifier in Step 4: Create the Line-Handler Process.
To obtain a list of running TCP6SAM processes, issue the following command:
> LISTDEV TCPIP
The SCF LISTDEV command lists all the TCP/IP processes. A program name in the
SCF LISTDEV display of TCPIP means that it's a conventional NonStop TCP/IP
process whereas a program name of TCP6SAM means it's a NonStop TCP/IPv6
process. Example 8-3 shows a sample result of the SCF LISTDEV TCPIP command.
Example 8-6. SCF LISTDEV TCPIP Command
1
2
3
4
5
6
7
8
9
SCF - T9082G02 - (05AUT99) (26JUL99) - 12/22/1999 14:52:00 System \NODEA
Copyright Hewlett-Packard Company
LDev
107
141
154
158
190
Name
$ZB017
$ZSAM1
$ZTC0
$ZB018
$ZSAM2
PPID
0,285
3,269
0,299
1,293
1,310
BPID
1,287
0,0
1,286
0,302
0.0
Type
(48,0)
(48,0)
(48,0)
(48,0)
(48,0)
RSize
32000
57344
32000
32000
57344
Pri
200
201
200
200
201
Program
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$DATA01.GUAR.TCP6SAM
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$SYSTEM.3.TCPIP
\NODEA.$DATA01.GUAR.TCP6SAM
In the above example, the processes $ZSAM1 and $ZSAM2 are TCP6SAM processes.
In NonStop TCP/IPv6, if logical network partitioning is not configured, all TCP6SAM
processes have access to all the IP addresses, so you can select any of the TCP6SAM
processes for the Expand line-handler process. However, if logical network partitioning
is configured, the TCP6SAM process you select for the ASSOCIATEDEV modifier must
be listed in the LNP field of the SUBNET you want to use.
In this example, we use $ZSAM1 as our TCP6SAM process. As shown in the
Example 8-5 on page 8-14, this TCP6SAM process is associated with the IP address
172.10.188.140.
The INFO SUBNET, DETAIL command shows the TCP6SAM processes that are
associated with configured LNPs. If you want to use the default partition in an
LNP-configured NonStop TCP/IPv6 environment, you have to perform several steps
because there is no direct way to determine the TCP6SAM process names for the
default partition. (The TCP6SAM process is not displayed in the INFO SUBNET,
DETAIL command.) To find TCP6SAM processes for the default partition, perform the
following steps:
1. Issue the SCF INFO SUBNET $ZZTCP.*, DETAIL command.
Expand Configuration and Management Manual—523347-008
8- 15
Configuring Expand-Over-IP Lines
Creating an Ethernet Subnet
2. Identify all TCP6SAM processes that are listed in the LNP field of the SUBNET
display and make a note of these process names.
3. Issue the SCF LISTDEV TCPIP command.
4. Use your list of TCP6SAM names to eliminate the LNP-assigned TCP6SAM
processes. The remaining TCP6SAM process(es) is associated with the default
LNP. This process has access only to the SUBNETs in the default partition.
For example, we know from the LISTDEV command shown in Example 8-5 that
$ZSAM1 is the only TCP6SAM process associated with an LNP so $ZSAM2, shown in
Example 8-6, is the TCP6SAM for the default partition.
Creating an Ethernet Subnet
If an Ethernet SUBNET does not already exist, you can create one using the SCF ADD
SUBNET command. The SCF ADD SUBNET command shown in the following
example defines an Ethernet SUBNET named SN1 for NonStop TCP/IPv6 in IPv4
mode or the TCP/IP/PL environment. The DEVICENAME modifier specifies the name
of the logical interface (LIF) that is used to communicate with the physical interface
(PIF) on an E4SA connected to the system.
-> ADD SUBNET $ZZTCP.*.SN1, TYPE ETHERNET, &
DEVICENAME $ZZLAN.LAN02, IPADDRESS 123.45.67.89,&
SUBNETMASK %HFFFFFF00
After the SUBNET is defined, it must be started using the SCF START SUBNET
command. The SCF START SUBNET command shown in the following example starts
the SUBNET named SN1:
-> START SUBNET $ZZTCP.*.SN1
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination IP address must be specified when
the local Expand-over-IP line-handler process is defined.
For more information about creating SUBNETs in the NonStop TCP/IPv6 environment,
refer to the TCP/IPv6 Configuration and Management Manual.
Step 2 (A): Identify an Available UDP Port
Number
A User Datagram Protocol (UDP) port number enables multiple applications to use
the same IP address. An Expand-over-IP line-handler process might share a local IP
address with other applications or with other Expand-over-IP processes. Each must
specify a different port number. To avoid conflict, you should identify an available UDP
port number for the IP address you selected in Step 1 (A): Select a Process and
SUBNET for NonStop TCP/IP Use.
Expand Configuration and Management Manual—523347-008
8- 16
Step 2 (B): Identify an Available UDP Port Number
for Parallel Library TCP/IP Use
Configuring Expand-Over-IP Lines
You can use the SCF STATUS PROCESS command to determine which UDP port
numbers are already in use for a particular SUBNET. Example 8-7 shows an example
of a SCF STATUS PROCESS command for the TCP/IP process named $ZTC01:
Example 8-7. SCF STATUS PROCESS Command
3-> STATUS PROCESS $ZTC01
TCPIP Status PROCESS \NODEA.$ZTC01
Status:
STARTED
PPID............ ( 0,311)
Proto
TCP
TCP
TCP
TCP
TCP
TCP
TCP
UDP
UDP
UDP
UDP
State
ESTAB
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
Laddr
172.16.35.15
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
BPID................... ( 1,292)
Lport
1057
9000
2563
telnet
ftp
finger
echo
1029
68
67
69
Faddr
155.186.68.137
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
Fport
5000
*
*
*
*
*
*
*
*
*
*
SendQ RecvQ
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
UDP port numbers are identified by UDP in the Proto field. UDP port numbers that are
in use are displayed in the Lport field. As shown in Example 8-7, the UDP port
numbers 1029, 68, 67, and 69 are in use.
Based on the information shown by the SCF STATUS PROCESS command, determine
an available UDP port number. HP recommends that you do not use a well-known
UDP port number in the range 0 to 1023. You must specify this UDP port number when
you define the Expand-over-IP line-handler process in Step 4: Create the Line-Handler
Process.
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination UDP port number must be
specified when the local Expand-over-IP line-handler process is defined.
Step 2 (B): Identify an Available UDP Port
Number for Parallel Library TCP/IP Use
A User Datagram Protocol (UDP) port number enables multiple applications to use
the same IP address. An Expand-over-IP line-handler process might share a local IP
address with other applications or with other Expand-over-IP processes. Each must
specify a different port number. To avoid conflict, you should identify an available UDP
port number for the IP address you selected in Step 1 (B): Select a TCPSAM Process
and SUBNET for Parallel Library TCP/IP Use.
Expand Configuration and Management Manual—523347-008
8- 17
Step 2 (C): Identify an Available UDP Port Number
for TCP/IPv6 Use
Configuring Expand-Over-IP Lines
You can use the SCF STATUS PROCESS command to determine which UDP port
numbers are already in use for a particular SUBNET. Example 8-8 shows an example
of a SCF STATUS PROCESS command for the TCPSAM process named $ZSAM1:
Example 8-8. SCF STATUS PROCESS Command for TCPSAM
3-> STATUS PROCESS $ZSAM1
TCPIP Status PROCESS \NODEC.$ZSAM1
Status:
STARTED
PPID............ ( 0,311)
Proto State
TCP ESTAB
UDP
UDP
UDP
UDP
Laddr
172.16.35.15
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
BPID................... ( 1,292)
Lport
1057
1029
68
67
69
Faddr
155.186.68.137
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
Fport
5000
*
*
*
*
SendQ RecvQ
0
0
0
0
0
0
0
0
0
0
UDP port numbers are identified by UDP in the Proto field. UDP port numbers that are
in use are displayed in the Lport field. As shown in Example 8-8, the UDP port
numbers 1029, 68, 67, and 69 are in use. Based on the information shown by the SCF
STATUS PROCESS command, determine an available UDP port number. HP
recommends that you do not use a well-known UDP port number in the range 0 to
1023. You must specify this UDP port number when you define the Expand-over-IP
line-handler process in Step 4: Create the Line-Handler Process.
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination UDP port number must be specified when the local Expand-over-IP line-handler process is defined.
Step 2 (C): Identify an Available UDP Port
Number for TCP/IPv6 Use
A User Datagram Protocol (UDP) port number enables multiple applications to use
the same IP address. An Expand-over-IP line-handler process might share a local IP
address with other applications or with other Expand-over-IP processes. Each must
specify a different port number. To avoid conflict, you should identify an available UDP
port number for the IP address you selected in Step 1 (C): Select a Process and
SUBNET for NonStop TCP/IPv6 Use.
You can use the SCF MON PROCESS command to determine which UDP port
numbers are already in use for a particular SUBNET. To obtain a list of available UDP
port numbers, issue the following SCF command:
> STATUS MON $ZZTCP.*
Example 8-9 shows a sample result of the SCF STATUS MON command.
Expand Configuration and Management Manual—523347-008
8- 18
Step 2 (C): Identify an Available UDP Port Number
for TCP/IPv6 Use
Configuring Expand-Over-IP Lines
Example 8-9. SCF STATUS MON Command
3-> STATUS MON $ZZTCP.*
TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM0
Status: STARTED, MASTER
PID............ ( 0,275)
Proto State
UDP
Laddr
16.107.187.84
Lport
5550
Faddr
0.0.0.0
Fport
*
SendQ
0
RecvQ
0
Faddr
Fport
SendQ
RecvQ
Laddr
Lport
Faddr
Fport
16.107.187.84
21600
0.0.0.0
*
--------------- 5050
--------------- *
Laddr fe80::a00:8eff:fe00:897b
Faddr ::
SendQ
0
0
RecvQ
0
0
SendQ
RecvQ
TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM1
Status: STARTED
PID............ ( 1,287)
Proto State
Laddr
Lport
TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM2
Status: STARTED
PID............ ( 2,293)
Proto State
UDP
UDP
TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM3
Status: STARTED
PID............ ( 3,271)
Proto State
Laddr
Lport
Faddr
Fport
UDP port numbers are identified by UDP in the Proto field. UDP port numbers that are
in use are displayed in the Lport field. As shown in Example 8-9, the UDP port
numbers 5500 and 21600 are in use. Based on the information shown by the SCF
STATUS MON command, determine an available UDP port number. HP recommends
that you do not use a well-known UDP port number in the range 0 to 1023. You must
specify this UDP port number when you define the Expand-over-IP line-handler
process in Step 4: Create the Line-Handler Process.
Note. You must also perform this step on the destination system before you can define the
local Expand-over-IP line-handler process. The destination UDP port number must be
specified when the local Expand-over-IP line-handler process is defined.
Expand Configuration and Management Manual—523347-008
8- 19
Configuring Expand-Over-IP Lines
Step 3: Create a Profile for the Line-Handler Process
Step 3: Create a Profile for the Line-Handler
Process
You can create a profile for a single-line Expand-over-IP line-handler process using the
PEXQSIP profile. This profile is provided in the $SYSTEM.SYSnn subvolume. You can
also create a new profile from an existing profile, or you can create your own profile.
For complete information about profiles, refer to the WAN Subsystem Configuration
and Management Manual.
This subsection shows you how to create a profile using PEXQSIP.
Note. Different profiles are provided for Expand-over-IP lines that are part of a multi-line path;
these profiles are described in Section 14, Configuring Multi-Line Paths.
ADD Profile Command
To create a profile from the PEXQSIP profile template, use the WAN subsystem SCF
ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create a device for the line-handler
process in Step 4: Create the Line-Handler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSIP is the disk filename of the profile provided for Expand-over-IP
line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSIP
profile are listed in Profile Modifiers on page 8-28.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSIP profile are described in Profile Modifiers on page 8-28.
Expand Configuration and Management Manual—523347-008
8- 20
Configuring Expand-Over-IP Lines
Example
Example
In the following example, a profile named SLHIP is created for a single-line Expandover-IP line-handler process using the PEXQSIP profile. The
AFTERMAXRETIRES_DOWN modifier is set in the profile.
-> ADD PROFILE $ZZWAN.#SLHIP, FILE $SYSTEM.SYS01.PEXQSIP, &
AFTERMAXRETRIES_DOWN
Step 4: Create the Line-Handler Process
You create a single-line Expand-over-IP line-handler process by adding it as a device
to the WAN subsystem.
Note. This section explains how to configure single-line Expand-over-IP line-handler
processes only. Creating an Expand-over-IP line that is part of a multi-line path is explained in
Section 14, Configuring Multi-Line Paths.
ADD DEVICE Command
To create an Expand-over-IP line-handler process, use the WAN subsystem SCF ADD
DEVICE command. The command syntax is as follows:
ADD
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,0 )
RSIZE rsize
ASSOCIATEDEV $tcpip_process
{IPVER_IPV4 | IPVER_IPV6}
SRCIPADDR src_ipddr
SRCIPPORT src_ipport
DESTIPADDR dest_ipaddr
DESTIPPORT dest_ipport
V6SRCIPADDR v6srcip-address
V6DESTIPADDR v6destip-address
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand line-handler
process to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
Expand Configuration and Management Manual—523347-008
8- 21
Configuring Expand-Over-IP Lines
ADD DEVICE Command
PROFILE profile_name
is the name of the profile you created for this Expand line-handler process in Step
3: Create a Profile for the Line-Handler Process.
CPU cpunumber
indicates the processor where this Expand line-handler process will normally
execute. This must be the same processor as that configured for the primary
NonStop TCP/IP process.
If you are using NonStop TCP/IPv6, you need not have the line handler on the
same CPU as the TCP6SAM process, but the line-handler process must be on the
same CPU as the monitor process.
If you are using Parallel Library TCP/IP, you need not have the line handler on the
same CPU as the TCPSAM process, but the line-handler process must be on the
same CPU as the monitor process.
ALTCPU altcpunumber
indicates the processor where the backup Expand line-handler process will
normally execute. This must be the same processor as that configured for the
NonStop TCP/IP process.
If you are using NonStop TCP/IPv6, you need not have the line handler on the
same CPU as the TCP6SAM process, but the line-handler process must be on the
same CPU as the monitor process.
If you are using Parallel Library TCP/IP, you need not have the line handler on the
same CPU as the TCPSAM process, but the line-handler process must be on the
same CPU as the monitor process.
TYPE (63,0)
is the device type and subtype for this Expand line-handler process. The device
type is always 63 for Expand line-handler processes. The subtype is 0 for singleline Expand-over-IP line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ASSOCIATEDEV tcpip_process
is a required modifier that specifies the device name of the NonStop TCP/IP,
TCPSAM, or TCP6SAM process you want to associate with this Expand-over-IP
line-handler process. The NonStop TCP/IP process must be configured in the
same processor pair as the Expand-over-IP line-handler process. There is no
default name.
Expand Configuration and Management Manual—523347-008
8- 22
Configuring Expand-Over-IP Lines
ADD DEVICE Command
{IPVER_IPV4 | IPVER_IPV6}
specifies whether the destination and source addresses are IPv4 or IPv6. The
default is IPv4. If IPVER is IPV4 (the default), then DESTIPADDR and
SRCIPADDR are required. If IPVER is IPV6, then V6DESTIPADDR and
V6SRCIPADDR are required. (This attribute applies to NonStop TCP/IPv6 only.)
SRCIPADDR src_ipaddr
if IPVER is IPv4 (the default), this is a required modifier that specifies an IP
address associated with the NonStop TCP/IP, TCPSAM, or TCP6SAM process
used by this Expand-over-IP line-handler process. This is the IP address you
selected in Step 1 (A): Select a Process and SUBNET for NonStop TCP/IP Use.
The address must be specified by number (for example, 130.252.12.3). It is not
validated and need not be accessible. The default is 0.0.0.1.
SRCIPPORT src_ipport
is a required modifier that specifies the UDP port number used by this Expandover-IP line-handler process. This is the port number you selected in Step 2 (A):
Identify an Available UDP Port Number. Valid values are in the range 0 through
65534. The default is 1024. HP recommends that you do not use a well-known port
in the range from 0 through 1023.
DESTIPADDR dest_ipaddr
if IPVER is IPv4 (the default), this is a required modifier that specifies the IP
address used by the remote (destination) Expand-over-IP line-handler process. It
is the IP address specified in the remote line-handler process’ SRCIPADDR
modifier. dest_ipaddr must be specified by number (for example,
130.252.12.3). Selecting IP addresses is described in Step 1 (A): Select a
Process and SUBNET for NonStop TCP/IP Use. It is not validated and need not be
accessible. The default is 0.0.0.1.
DESTIPPORT dest_ipport
is a required modifier that specifies the UDP port number used by the remote
(destination) Expand-over-IP line-handler process. It is the port number specified in
the remote line-handler process’ SRCIPPORT modifier. Selecting port numbers is
described in Step 2 (A): Identify an Available UDP Port Number. Valid values are in
the range 0 through 65534. The default is 1024. HP recommends that you do not
use a well-known port in the range from 0 through 1023.
V6SRCIPADDR v6srcip-address
if IPVER is IPv6, this is a required modifier that specifies an IP address associated
with the TCP6SAM process used by this Expand-over-IP line-handler process.
This is the IP address you selected in Step 1 (C): Select a Process and SUBNET
for NonStop TCP/IPv6 Use. The address must be specified by number (for
example, 31CA:B145:5489:1034:1784:B245:4029:1257). It is not validated and
need not be accessible. (This attribute applies to NonStop TCP/IPv6 only.)
Expand Configuration and Management Manual—523347-008
8- 23
Configuring Expand-Over-IP Lines
Considerations
V6DESTIPADDR v6destip-address
if IPVER is IPv6, this is a required modifier that specifies the IP address used by
the remote (destination) Expand-over-IP line-handler process. It is the IP address
specified in the remote line-handler process’ V6SRCIPADDR modifier.
v6dest_ipaddr must be specified by number (for example,
1611:1071:F881:1167:1611:A071:1881:B167). Selecting IP addresses is described
in Step 1 (C): Select a Process and SUBNET for NonStop TCP/IPv6 Use. It is not
validated and need not be accessible. (This attribute applies to NonStop TCP/IPv6
only.)
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 through 254) of the system
connected to the other end of the line. If you do not specify the NEXTSYS modifier,
it defaults to an invalid value (255), and an operator message occurs during the
initialization of the Expand-over-IP line-handler process. The path will not be
operational until you alter the NEXTSYS modifier to a valid value using either the
WAN subsystem SCF ALTER DEVICE command or the Expand subsystem SCF
ALTER PATH command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this Expand line-handler process.
Modifier names in the PEXQSIP profile are listed in Profile Modifiers on page 8-28.
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXQSIP profile are
described in Profile Modifiers on page 8-28.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Expand Configuration and Management Manual—523347-008
8- 24
Configuring Expand-Over-IP Lines
Examples
Examples
In the following example, a device named $IPLIN1 is created for a single-line Expandover-IP line-handler process. The PATHPACKETBYTES modifiers are recommended
for Expand-over-IP lines.
-> ADD DEVICE $ZZWAN.#IPLIN1, PROFILE SLHIP, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 251, ASSOCIATEDEV $ZB01A, &
DESTIPADDR 130.252.31.245, DESTIPPORT 1240, &
SRCIPADDR 130.252.31.150, SRCIPPORT 1231, PATHPACKETBYTES 9180&
PATHBLOCKBYTES 9180
In the next example, the same device is created for a NonStop TCP/IPv6 process.
Note that since IPVER_IPV4 is the default, it does not need to be explicitly specified for
NonStop TCP/IP; only IPVER_IPV6 must be specified, as in the following example.
-> ADD DEVICE $ZZWAN.#IPLIN1, PROFILE SLHIP, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), RSIZE 0, &
PATHTF 3, IPVER_IPV6, NEXTSYS 251, ASSOCIATEDEV $ZSAM1, &
V6SRCIPADDR 31CA:B145:5489:1034:1784:B245:4029:1257, &
V6DESTIPADDR 1611:1071:F881:1167:1611:A071:1881:B167, &
SRCIPPORT 11171, & DESTIPPORT 11171, PATHPACKETBYTES 9180, &
PATHBLOCKBYTES 9180
In the next example, the same device is created as part of a multi-CPU path. The
SUPERPATH_ON and L4EXTPACKETS_ON modifiers are required for line-handler
processes that are part of a multi-CPU path. The L4CONGCTRL_ON modifier is
recommended for Expand line-handler processes that are part of a multi-CPU path.
-> ADD DEVICE $ZZWAN.#IPLIN1, PROFILE SLHIP, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 251, ASSOCIATEDEV $ZB01A, &
DESTIPADDR 130.252.31.245, DESTIPPORT 1240, &
SRCIPADDR 130.252.31.150, SRCIPPORT 1231, PATHPACKETBYTES 9180,&
PATHBLOCKBYTES 9180, SUPERPATH_ON
Step 5: Start the Line-Handler Process
To start a single-line Expand-over-IP line-handler process, use the WAN subsystem
SCF START DEVICE command. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
device_name
is the device name of the Expand-over-IP line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Expand Configuration and Management Manual—523347-008
8- 25
Configuring Expand-Over-IP Lines
Step 6: Start the Line
Step 6: Start the Line
To start an Expand-over-IP line, use the Expand subsystem SCF START LINE
command. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-IP line-handler process.
The successful completion of this command leaves the line in the STARTED state.
Add a Configured Tunnel for an Expand Line
These examples show how to add a configured IPv6-to-IPv4 tunnel for an Expand line
between \NodeB and \NodeC. The first two examples are configured at the host
\NodeB and the second two examples are configured at the host \NodeC.
Note. These examples apply to NonStop TCP/IPv6 only.
Example 8-10 shows how to configure an Expand line using configured-tunnel for
\NodeB.
Example 8-10. \NodeB: Configure an Expand-over-TCP/IPv6 Line Using
Configured-Tunnel
Add subnet sn2, type ethernet, family dual, ipaddress 16.107.190.91, &
devicename lan04, subnetmask %hffffff00, ipv6prefix "3ffe:a::/64"
Start subnet sn2
Add subnet ipt1, type tunnel, iptsrc 16.107.190.91, iptdst 16.107.188.104, &
family inet6
Alter subnet ipt1, family inet6, ipv6 up
Start subnet ipt1
Info subnet ipt1, detail
== Use ipv6address of configured-tunnel for ipv6gateway route.
Add route v6rt1, family inet6, ipv6destination "3ffe:b::/64", &
ipv6gateway "fe80::106b:be5b", subnet "ipt1"
Start route v6rt1
Expand Configuration and Management Manual—523347-008
8- 26
Configuring Expand-Over-IP Lines
Add a Configured Tunnel for an Expand Line
Example 8-11 shows how to add an Expand line from \NodeB to \NodeC.
Example 8-11. Add an Expand Line to \NodeC
allow all errors
abort line $giplco1
stop device $zzwan.#giplco1
delete device $zzwan.#giplco1
== Add profile of IP line
ADD PROFILE $zzwan.#afkslhip, file $data00.t9057afk.sippfr
== Add Expand line handler.
ADD DEVICE $ZZWAN.#giplco1, CPU 2, ALTCPU 3, PROFILE afkslhip,&
IOPOBJECT $data00.t9057afk.lhobj,TYPE (63,0), rsize 1, &
nextsys 102, associatedev $zsam0, &
ipver_ipv6, &
destipaddr 16.107.187.84, destipport 5050, &
srcipaddr 16.107.186.66 , srcipport 5050, &
v6srcipaddr 3FFE:A::A00:8EFF:FE03:812E, &
v6destipaddr 3FFE:B::A00:8EFF:FE00:897C
delay 2
info device $zzwan.#giplco1
start device $zzwan.#giplco1
Example 8-12 shows how to configure an Expand line using configured-tunnel for
\NodeC.
Example 8-12. \NodeC: Configure an Expand-over-NonStop TCP/IPv6 Line Using
Configured-Tunnel
Add subnet sn2, type ethernet, family dual, ipaddress 16.107.188.104, &
devicename lan04, subnetmask %hffffff00, ipv6prefix "3ffe:b::/64"
Start subnet sn2
Add subnet ipt1, type tunnel, iptsrc 16.107.188.104, iptdst 16.107.190.91, &
family inet6
Alter subnet ipt1, family inet6, ipv6 up
Start subnet ipt1
Info subnet ipt1, detail
== Use ipv6address of configured-tunnel for ipv6gateway route.
Add route v6rt1, family inet6, ipv6destination "3ffe:a::/64", &
ipv6gateway "fe80::106b:bc68", subnet "ipt1"
Start route v6rt1
Expand Configuration and Management Manual—523347-008
8- 27
Configuring Expand-Over-IP Lines
Profile Modifiers
Example 8-13 shows how to add an Expand line from \NodeC to \NodeB.
Example 8-13. Add an Expand Line to \NodeB
allow all errors
abort line $giplba1
stop device $zzwan.#giplba1
delete device $zzwan.#giplba1
== Add profile of IP line
ADD PROFILE $zzwan.#afkslhip, file $data00.t9057afk.sippfr
== Add Expand line handler.
ADD DEVICE $ZZWAN.#giplba1, CPU 2, ALTCPU 3, PROFILE afkslhip,&
IOPOBJECT $data00.t9057afk.lhobj,TYPE (63,0), rsize 1, &
nextsys 211, associatedev $zsam0, &
ipver_ipv6, &
destipaddr 16.107.186.66, destipport 5050, &
srcipaddr 16.107.187.84 , srcipport 5050, &
v6srcipaddr 3FFE:B::A00:8EFF:FE00:897C, &
v6destipaddr 3FFE:A::A00:8EFF:FE03:812E
delay 2
info device $zzwan.#giplba1
start device $zzwan.#giplba1
Profile Modifiers
This subsection lists the recommended modifiers for single-line Expand-over-IP
line-handler processes and describes the modifiers provided for configuring special
features. It also describes default values and value ranges for all the modifiers
contained in the PEXQSIP profile.
Note. A different profile is provided for Expand-over-IP lines that are part of a multi-line path;
this profile is described in Section 14, Configuring Multi-Line Paths.
Recommended Modifiers
Recommended modifiers are modifiers that should be used to obtain optimum
performance and efficiency.
L4CONGCTRL_ON
Default: ON for single-line paths, OFF for multi-line paths (because it is shared by all
line types)
Units:
Not applicable
Range: ON or OFF
This modifier enables the congestion control mechanism. Because data transfer with
the UDP is not guaranteed, the Expand End-to-End protocol is used to achieve reliable
communications for Expand-over-IP connections. You can avoid congestion and
improve error recovery by using the L4CONGCTRL_ON modifier.
Expand Configuration and Management Manual—523347-008
8- 28
Configuring Expand-Over-IP Lines
Modifiers for Special Features
L4CONGCTRL is a path parameter and the path profile sets L4CONGCTRL_OFF
because it is shared by all line types. Therefore, multi-line IP paths default to
L4CONGCTRL_OFF and must specify L4CONGCTRL_ON.
The L4CONGCTRL_ON modifier is also recommended for Expand line-handler
processes that are part of a multi-CPU path.
You should read the description of the congestion control feature in Section 18,
Subsystem Description, before using this modifier. The L4CONGCTRL_ON modifier is
described in detail in Section 17, Expand Modifiers.
PATHPACKETBYTES n
Default:
Units:
Range:
1024
Bytes
0 or 1024 through 9152
This modifier enables the variable packet size feature and specifies the maximum size,
in bytes, of a variable packet. PATHPACKETBYTES can be used on Expand-over-IP
lines to increase the size of frames transmitted between neighboring nodes. It should
be set to 9152 for best performance.
You should read the description of the variable packet size feature in Section 18,
Subsystem Description, before using this modifier. The PATHPACKETBYTES modifier
is described in detail in Section 17, Expand Modifiers.
Modifiers for Special Features
In addition to the L4CONGCTRL_ON and PATHPACKETBYTES modifiers, the
SUPERPATH_ON modifier is provided in the PEXQSIP profile to enable you to
configure the Expand multi-CPU feature.
For configuration considerations for all special features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of each feature,
refer to Section 3, Planning a Network Design.
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
PEXQSIP Modifiers
The disk file $SYSTEM.SYSnn.PEXQSIP defines modifiers for single-line Expandover-IP line-handler processes.
Table 8-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Expand Configuration and Management Manual—523347-008
8- 29
PEXQSIP Modifiers
Configuring Expand-Over-IP Lines
Table 8-1. PEXQSIP Modifiers for Expand-over-IP Lines (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
None
Any 8-character string
COMPRESS_OFF
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
DESTIPADDR 2
0.0.0.0
Any 36-character string
DESTIPPORT 1
1024
0 through 65534
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
EXTMEMSIZE
2048
0 through 32767
FRAMESIZE
132
64 through 2047
IPVER_IPV4
3
IPVER_IPV6
L2RETRIES
20
1 through 255
L4CONGCTRL_OFF
L4CONGCTRL_ON
3
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS3
255
0 to 254
OSSPACE
32767
3072 to 32767
OSTIMEOUT
300
10 to 32767
PATHBLOCKBYTES4
0
0 through 9152 or 9180
PATHPACKETBYTES4
1024
0 through 9152 or 9180
PATHTF
0
0 through 186
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60
0 to 77600 (12hrs)
Expand Configuration and Management Manual—523347-008
8- 30
PEXQSIP Modifiers
Configuring Expand-Over-IP Lines
Table 8-1. PEXQSIP Modifiers for Expand-over-IP Lines (page 2 of 2)
Modifier
Default Value
Range of Values
RETRYPROBE
19
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
SRCIPADDR2
0.0.0.0
Any 36-character string
SRCIPPORT1
1024
0 through 65534
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
3
SUPERPATH_ON
TIMERINACTIVITY
0 (no timer)
0 through 32767
TIMERPROBE
1
1 through 32767
TIMERRECONNECT
30
30 through 32767
TXWINDOW
7
2 through 25
V6DESTIPADDR
0000:0000:0000:
0000:0000:0000:
0000:0000
Any 45-character string
V6SRCIPADDR
0000:0000:0000:
0000:0000:0000:
0000:0000
Any 45-character string
1. This is a required modifier.
2. This is a required modifier. See the TCP/IPv6 Configuration and Management Manual for IP address syntax.
3. This is a required modifier. The default value is invalid and must be changed.
4. The maximum value is actually 9180, but for performance it is best to use whole multiples of 32, which would
result in a 9152 maximum.
Expand Configuration and Management Manual—523347-008
8- 31
Configuring Expand-Over-IP Lines
Expand Configuration and Management Manual—523347-008
8- 32
PEXQSIP Modifiers
9
Configuring Expand-Over-ATM Lines
The Expand-over-ATM line-handler process provides connectivity to an Asynchronous
Transfer Mode (ATM) network.
In addition, the Expand-over-ATM line-handler process can use the services of the
ServerNet LAN systems access (SLSA) subsystem to provide Expand-over-ATM
connections.
The ATM subsystem provides a PVC and SVC connection, whereas the SLSA
subsystem provides an ATMSAP with lifname connection that enables you to manage
PVC connections under SLSA. In other words, the ATMSAP connection is identical
with a PVC connection; only the subsystem is different, which could potentially make
your subsystem configuration process easier.
An Expand-over-ATM line-handler process can be configured as a single line, as part
of a multi-line path, or as part of multi-CPU path.
This section explains how to configure an Expand-over-ATM line-handler process as a
single-line or as part of a multi-CPU path. Configuring Expand-over-ATM lines that are
part of a multi-line path is explained in Section 14, Configuring Multi-Line Paths.
Note. Multi-line paths are not recommended. For fault tolerance (i.e. a backup line) a multiCPU path (superpath) is the recommended approach.
Expand Configuration and Management Manual—523347-008
9 -1
Required Hardware and Software
Configuring Expand-Over-ATM Lines
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-ATM line-handler process to provide Expand-over-ATM connectivity. These
components are illustrated in Figure 9-1 and are explained in the following
subsections.
Figure 9-1. Expand-Over-ATM Connectivity Components
Processor
QIO
Shared
Memory
Segment
Expand-Over-ATM
Line-Handler
Process
ATM Subsystem or
SLSA Subsystem
Y-Fabric
X-Fabric
ATM3SA
CDT 055.CDD
QIO Subsystem
QIO is a mechanism for transferring data between processes through a shared
memory segment. The QIO subsystem is preconfigured and started during the system
load sequence. The QIO subsystem must be started and running before Expand
line-handler processes can be started.
Refer to Shared Memory Area for QIO on page 18-48 for information on QIO
enhancements that enable you to have more control over certain aspects of memory
management. For information about the QIO subsystem, refer to the QIO Configuration
and Management Manual.
Expand Configuration and Management Manual—523347-008
9 -2
Configuring Expand-Over-ATM Lines
ATM Subsystem
ATM Subsystem
ATM is a cell-switching and multiplexing technology that combines the benefits of
circuit switching (constant transmission delay and guaranteed capacity) with those of
packet switching (flexibility and intermittent traffic). The ATM subsystem is the HP
implementation of the ATM technology. The ATM subsystem supports the ATM UserNetwork Interface (UNI) Specification Version 3.0 over a 155 Mbps SONET STS-3c
connection.
For information about configuring and managing the ATM subsystem, refer to the ATM
Configuration and Management Manual.
SLSA Subsystem
The SLSA subsystem provides access to parallel LAN and WAN I/O for NonStop
S-series servers. The SLSA subsystem provides access to Ethernet, Fast Ethernet,
Gigabit Ethernet, token-ring, CCSA, multifunction I/O-board Ethernet adapters, the
ServerNet wide area network (SWAN) concentrator, and to Expand-over-ATM line
handlers through ATM3SA adapters.
For information about the SLSA subsystem, refer to the LAN Configuration and
Management Manual.
ATM 3 ServerNet Adapter (ATM3SA)
The ATM3SA provides one bidirectional full-duplex ATM 0C3 port for connection to the
UNI. The UNI is an interface point between ATM end users and a private ATM switch,
or between a private ATM switch and the public carrier ATM network. The UNI
interface is defined by standards adopted by the ATM Forum.
For information about installing an ATM3SA, refer to the ATM Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
9 -3
Topology Considerations
Configuring Expand-Over-ATM Lines
Topology Considerations
In a single-line configuration, you configure one Expand-over-ATM line-handler
process for each path to an adjacent node. In a multi-CPU path configuration, you
configure multiple Expand-over-ATM line-handler processes, usually in separate
processors, for each path to an adjacent node. In a multi-line path configuration, you
configure a path that consists of multiple lines between adjacent nodes.
In Figure 9-2, a single-line path is configured between node \A and node \B; a multiCPU path that consists of two paths is configured between node \A and node \C; and a
multi-line path that consists of three lines is configured between node \C and node \D.
Figure 9-2. Expand-Over-ATM Line-Handler Process Topology
Node \B
Node \A
CPU 0
CPU 0
LH
LH
Single-line Path
CPU 1
CPU 2
LH
LH
Multi-CPU Path
LH
CPU 1
LH
CPU 2
LH
CPU 3
Node \C
LH
Multiline Path
CPU 1
Node \D
Expand Configuration and Management Manual—523347-008
9 -4
CDT 056.CDD
Summary of Configuration Steps
Configuring Expand-Over-ATM Lines
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 9-2 for details), configuring and starting a single-line
Expand-over-ATM line-handler process involves the following steps:
Step
Tool Used
Step 1: Identify the ATM Connection
SCF interface to the ATM subsystem
Step 2: Create a Profile for the Line-Handler Process
SCF interface to the WAN
subsystem
Step 3: Create the Line-Handler Process
SCF interface to the WAN
subsystem
Step 4: Start the Line-Handler Process
SCF interface to the WAN
subsystem
Step 5: Start the Line
SCF interface to the Expand
subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure
Expand-over-ATM line-handler processes; it is not meant to show the complete syntax of SCF
commands described. Refer to the following manuals for more information:
•
•
•
ATM Configuration and Management Manual for ATM subsystem commands
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF commands
Step 1: Identify the ATM Connection
Note. The following procedure assumes that an ATM3SA has already been installed and
configured. For complete information about installing and configuring an ATM3SA, refer to the
ATM Configuration and Management Manual.
The ATM subsystem provides permanent virtual circuit (PVC), switched virtual
circuit (SVC), or ATM protocol direct service access point (ATMSAP) connections.
A PVC connection is permanently established while an SVC connection is dynamically
established. An ATMSAP connection uses the ServerNet LAN systems access (SLSA)
subsystem, but is the same type of connection as PVC.
You configure your Expand-over-ATM line-handler process differently depending on
whether it will use a PVC, SVC, or ATMSAP connection.
Expand Configuration and Management Manual—523347-008
9 -5
Configuring an Expand Line-Handler Process That
Uses a PVC
Configuring Expand-Over-ATM Lines
Configuring an Expand Line-Handler Process That Uses a PVC
If your Expand-over-ATM line-handler process will use a PVC connection, you must
identify the PVC you plan to use. The SCF INFO PVC command displays the
configured name of a PVC.
Example 9-1 shows an example of an SCF INFO PVC command for an ATM line
named $AM1.
Example 9-1. SCF INFO PVC Command
1-> INFO PVC $AM1.#IP.*
ATM Info PVC
Name
$AM1.#IP.PVC1
*VPI
23
*VCI
35
The PVC name is displayed in the Name field. As shown in Example 9-1, a PVC named
$AM1.#IP.PVC1 is configured for line $AM1. PVC names take the following form:
$line-name.#atmsap-name.pvc-name.
where $line-name is the name of the ATM line to which the PVC is subordinate,
#atmsap-name is the name of the service access point (SAP) to which service is
being provided, and pvc-name is the name assigned to the PVC. You specify the
pvc-name part of the PVC name when you configure the Expand-over-ATM
line-handler process in Step 3: Create the Line-Handler Process.
Note. #IP is currently the only supported SAP.
Configuring an Expand Line-Handler Process That Uses an SVC
If your Expand-over-ATM line-handler process will use an SVC connection, you must
•
•
Obtain selector bytes for the ATM lines that will be used by the Expand-over-ATM
line-handler processes at both the local and the remote systems.
Identify the ATM address configured for the ATM line that will be used by the
Expand-over-ATM line-handler process at the remote system.
Obtaining Selector Bytes for the Local and Remote ATM
Lines
The selector byte is the last (rightmost) byte of a 20-byte hexadecimal ATM address.
It is used by the ATM subsystem to direct incoming call requests to the correct ATM
subsystem client. Selector bytes must be coordinated among ATM clients using the
same ATM line.
You must obtain unique selector bytes from your network administrator (or whoever
coordinates selector bytes in your ATM network) for the ATM lines that will be used by
Expand Configuration and Management Manual—523347-008
9 -6
Configuring an Expand Line-Handler Process That
Uses an SVC
Configuring Expand-Over-ATM Lines
your local and remote Expand-over-ATM line-handler processes. Specifying a selector
byte when configuring an Expand-over-ATM line-handler process is described in Step
3: Create the Line-Handler Process.
Identifying the ATM Address Configured for the Remote ATM
Line
You can use the ATM subsystem SCF INFO LINE command with the DETAIL option to
display the ATM address configured for the ATM line that will be used by the Expandover-ATM line-handler process at the remote system.
Example 9-2 shows an example of an ATM subsystem SCF INFO LINE command with
the DETAIL option for an ATM line named $AM1 on the remote system \NODEA.
Example 9-2. ATM Subsystem SCF INFO LINE, DETAIL Command
3-> INFO LINE $AM1, DETAIL
ATM Detailed Info LINE \NODEA.$AM1
*ATMADDR................. ISONSAP: 47
1A
Registered Atm Address... ISONSAP: 47
1A
*UNIVERSION.............. 3.0
00
29
00
29
05
EB
05
EB
80
00
80
00
FF
00
FF
00
E1
00
E1
00
00
00
00
00
00
01
00
01
00
B3
00
B3
F2
00H
F2
00H
UME
*UMECOMMUNITY............
*UMEVPI. ................ 1
*MAXPVCVPI............... 100
*UMEVCI................... 16
*MAXPVCVCI...... ......... 100
PHYSICAL LAYER
Phys Layer Media Type.... MULTIMODE
Phys Layer Xmit Type .... SONET
*MAXVPCS................. 100
*MAXVPIBITS.............. 8
*UNIPORTTYPE............. PRIVATE
ATM LAYER
*MAXVCCS.................. 1000
*MAXVCIBITS............... 10
The ATM address is shown in the ATMADDR (configured ATM address) field. As
shown in Example 9-2, the 20-byte hexadecimal ATM address configured for line
$AM1 is as follows:
47000580FFE1000000F21A29EB0000000001B300
You must replace the last byte of this ATM address with the selector byte you obtained
for the remote ATM line when specifying the ATM address during Expand-over-ATM
line-handler configuration. For example, if the selector byte you obtained is %H81, then
you would specify the following ATM address during Expand-over-ATM line-handler
configuration:
47000580FFE1000000F21A29EB0000000001B381
Expand Configuration and Management Manual—523347-008
9 -7
Configuring an Expand Line-Handler Process That
Uses an SVC
Configuring Expand-Over-ATM Lines
Specifying an ATM address when configuring an Expand-over-ATM line-handler
process in described in Step 3: Create the Line-Handler Process.
Verifying the ATM Address and Selector Byte Configuration
After you have configured the local and remote Expand-over-ATM line-handler
processes as described in Step 3: Create the Line-Handler Process, you can verify that
the correct ATM addresses and selector bytes are configured using the Expand
subsystem SCF INFO LINE command with the DETAIL option.
Example 9-3 shows an example of an Expand subsystem SCF INFO LINE command
with the DETAIL option for an Expand-over-ATM line-handler process named
$ATMBAT and a CallType of SVC.
Example 9-3. Expand Subsystem SCF INFO LINE, DETAIL Command for SVC
-> INFO LINE $ATMBAT, DETAIL
EXPAND
Detailed Info
LINE
$ATMBAT
(LDEV
206)
L2Protocol
Net^Atm TimeFactor......
570K *SpeedK........
Framesize.......
132 -Rsize...........
3 -Speed........
*LinePriority....
1 StartUp.........
OFF Delay.........
*DownIfBadQuality
OFF *QualityThreshold
96 *QualityTimer..
*Txwindow........
7 *Maxreconnects...
0 *AfterMaxRetries
*Timerreconnect 0:00:30.00 *Retryprobe......
3 *Timerprobe....
*Associatedev....
$AM1 *Associatesubdev
#IP *Timerinactivity
ConnEp....... %H00000000 ListenEp.... %H00000000 *CallType......
*AtmSel......
%H80
*DestAtmAddr.. (ISONSAP:%H47009181000100006170597C0140000C80001081)
NOT_SET
0:00:00.10
0:01:00.00
PASSIVE
0:00:30.00
0:00:00.00
SVC
The selector byte obtained for the local ATM line is displayed in the AtmSel field and
the ATM address for the ATM line used by the remote Expand-over-IP line-handler
process (including the selector byte for that ATM line) is displayed in the
DestAtmAddr field. As shown in Example 9-3, the selector byte for the local ATM line
is %H80 and the selector byte the remote ATM line is %H81.
Note. You cannot display the selector bytes currently in use using the ATM subsystem SCF
INFO LINE command (shown in Example 9-2) because the ATM subsystem SCF INFO LINE
command only displays static configuration information.
Expand Configuration and Management Manual—523347-008
9 -8
Configuring an Expand Line-Handler Process That
Uses ATMSAP
Configuring Expand-Over-ATM Lines
Configuring an Expand Line-Handler Process That Uses
ATMSAP
The SLSA ATMSAP connection offers an ATM Native Mode network interconnect
support similar to that offered by the PVC object within the ATM subsystem. Expand
issues native mode frames directly to the ATM product via a LIF associated with an
ATMSAP object.
Figure 9-3 illustrates ATMSAP use by Expand.
Figure 9-3. Expand and ATMSAP
CPU
CPU
ATM3SA
Expand LH
Process
Line
LIF
ATMSAP
ATM3SA
ATMSAP
Expand LH
Process
LIF
Line
CDT 003.CDD
For more information on ATMSAP objects, including their management by the SCF
ABORT, ADD, ALTER, DELETE, INFO, NAMES, START, STATS, STATUS, and STOP
commands, refer to the LAN Configuration and Management Manual.
To configure an ATMSAP object:
1. Use the ADD ATMSAP command to add an ATMSAP object. You can add a
maximum of 128 ATMSAP objects per PIF object. Following is an example of the
ADD ATMSAP command:
ADD [ /OUT file-spec/ ] ATMSAP $ZZLAN.ATM01.0.A.ATMSAP01, &
VCC (vpi, vci)
The example above adds an ATMSAP object named
$ZZLAN.ATM01.0.A.ATMSAP01.
2. Add a LIF Object to an ATMSAP Object. Use the ADD LIF command to configure a
LIF for each ATMSAP object. Following is an example of the ADD LIF command
that adds a LIF object and associates it with an ATMSAP object.
ADD LIF $ZZLAN.LIF01, ATMSAP ATM01.0.A.ATMSAP01
The example above adds a LIF object named $ZZLAN.LIF01 and associates it to
an ATMSAP object named $ZZLAN.ATM01.0.A.ATMSAP01.
Expand Configuration and Management Manual—523347-008
9 -9
Step 2: Create a Profile for the Line-Handler Process
Configuring Expand-Over-ATM Lines
Verifying the Line-Handler Process
Example 9-4 shows an example of an Expand subsystem SCF INFO LINE command
with the DETAIL option of an Expand-over-ATM line-handler process named
$ATM2BAT and a CallType of ATMSAP.
Example 9-4. Expand Subsystem SCF INFO LINE, DETAIL Command for
ATMSAP
-> INFO LINE $ATM2BAT, DETAIL
EXPAND
Detailed Info
L2Protocol
Framesize....
*LinePriority...
*DownIfBadQuality
*Txwindow...
*Timerreconnect
*CallType...
LINE
Net^Atm
132
1
OFF
7
0:00:30.00
ATMSAP
$ATM2BAT
(LDEV
613)
TimeFactor...
26K
-Rsize....
StartUp...
OFF
*QualityThreshold 96
*Maxreconnects...
0
*Retryprobe…….
3
*LifName..
ATM2LIF
*SpeedK...
-Speed...
Delay...
*QualityTimer
*AfterMaxRetries
*Timerprobe…
*Timerinactivity
OC3
0:00:00.10
0:01:00.00
PASSIVE
0:00:30.00
0:00:00.00
Example 9-5 shows examples of altering the modifier CALLTYPE and the LIFNAME of
an Expand-over-ATM line-handler process named $ATM2BAT.
Example 9-5. Altering the CALLTYPE Modifier and LIFNAME
-> ALTER LINE $ATM2BAT, CALLTYPE
ATMSAP
-> ALTER LINE $ATM2BAT, LIFNAME LIFEXP01
Step 2: Create a Profile for the Line-Handler
Process
You can create a profile for a single-line Expand-over-ATM line-handler process using
the PEXQSATM profile. This profile is provided in the $SYSTEM.SYSnn subvolume.
You can also create a new profile from an existing profile, or you can create your own
profile. For complete information about profiles, refer to the WAN Subsystem
Configuration and Management Manual.
This subsection shows you how to create a profile using PEXQSATM.
Note. Different profiles are provided for Expand-over-ATM lines that are part of a multi-line
path; these profiles are described in Section 14, Configuring Multi-Line Paths.
Expand Configuration and Management Manual—523347-008
9- 10
Configuring Expand-Over-ATM Lines
ADD Profile Command
ADD Profile Command
To create a profile from the PEXQSATM profile template, use the WAN subsystem SCF
ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create a device for the line-handler
process in Step 3: Create the Line-Handler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSATM is the disk filename of the profile provided for Expand-overATM line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSATM
profile are listed in Profile Modifiers on page 9-17.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSATM profile are described in Profile Modifiers on page 9-17.
Example
In the following example, a profile named SLHATM is created for a single-line Expandover-ATM line-handler process using the PEXQSATM profile. The
AFTERMAXRETIRES_DOWN modifier is set in the profile.
-> ADD PROFILE $ZZWAN.#SLHATM, FILE $SYSTEM.SYS01.PEXQSATM, &
AFTERMAXRETRIES_DOWN
Expand Configuration and Management Manual—523347-008
9- 11
Configuring Expand-Over-ATM Lines
Step 3: Create the Line-Handler Process
Step 3: Create the Line-Handler Process
You create a single-line Expand-over-ATM line-handler process by adding it as a
device to the WAN subsystem.
Note. This section explains how to configure single-line Expand-over-ATM line-handler
processes only. Creating an Expand-over-ATM line that is part of a multi-line path is explained
in Section 14, Configuring Multi-Line Paths.
ADD DEVICE Command
To create an Expand-over-ATM line-handler process, use the WAN subsystem SCF
ADD DEVICE command. The command syntax depends on whether you use a PVC,
SVC, or ATMSAP connection.
Syntax for PVC Connections
Use the following command syntax if the Expand-over-ATM line-handler process will
use a PVC connection:
ADD
,
,
,
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,0 )
RSIZE rsize
ASSOCIATEDEV $atm_line
ASSOCIATESUBDEV #IP
CALLTYPE_PVC
PVCNAME pvc-name
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
Expand Configuration and Management Manual—523347-008
9- 12
Configuring Expand-Over-ATM Lines
ADD DEVICE Command
Syntax for SVC Connections
Use the following command syntax if the Expand-over-ATM line-handler process will
use an SVC connection:
ADD
,
,
,
,
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSTEM.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,0 )
RSIZE rsize
ASSOCIATEDEV $atm_line
ASSOCIATESUBDEV #IP
CALLTYPE_SVC
ATMSEL selector-byte
DESTATMADDR (ISONSAP:%Hatm-address)
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
Syntax for ATMSAP Connections
Use the following command syntax if the Expand-over-ATM line-handler process will
use an ATMSAP connection:
ADD
,
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSTEM.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,0 )
RSIZE rsize
CALLTYPE_ATMSAP
LIFNAME lif_name
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand line-handler
process to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for this Expand line-handler process in Step
2: Create a Profile for the Line-Handler Process.
Expand Configuration and Management Manual—523347-008
9- 13
Configuring Expand-Over-ATM Lines
ADD DEVICE Command
CPU cpunumber
indicates the processor where this Expand line-handler process will normally
execute.
ALTCPU altcpunumber
indicates the processor where the backup Expand line-handler process will
normally execute.
TYPE (63,0)
is the device type and subtype for this Expand line-handler process. The device
type is always 63 for Expand line-handler processes. The subtype is 0 for singleline Expand-over-ATM line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ASSOCIATEDEV atm-line
specifies the device name of the ATM line you want to associate with this Expandover-ATM line-handler process, for example, $ATM1. This parameter is required.
ASSOCIATESUBDEV #IP
identifies the ATM service access point (SAP). The only currently supported ATM
SAP is #IP.
CALLTYPE_PVC
indicates that a permanent virtual circuit (PVC) connection will be used.
CALLTYPE_SVC
indicates that a switched virtual circuit (SVC) connection will be used.
CALLTYPE_ATMSAP
indicates that an ATMSAP connection through the SLSA subsystem will be used.
LIFNAME lif-name
is the name of the logical interface, which represents the name by which LAN
access is known to the system. This name can be up to 8 characters long, nullterminated, and case-sensitive.
This modifier is only applicable to ATMSAP connections using the SLSA
subsystem.
Expand Configuration and Management Manual—523347-008
9- 14
Configuring Expand-Over-ATM Lines
ADD DEVICE Command
PVCNAME pvc-name
is the name of the permanent virtual circuit (PVC) that will be used. This is the PVC
name you identified in Step 1: Identify the ATM Connection on page 9-5. For
example, PVC01.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use PVC connections.
ATMSEL selector-byte
is a hexadecimal selector byte for the ATM line used by this Expand-over-ATM
line-handler process. This is the selector byte you obtained in Obtaining Selector
Bytes for the Local and Remote ATM Lines on page 9-6.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use SVC connections.
DESTATMADDR (ISONSAP:%Hatm-address)
is the 20-byte hexadecimal ATM address configured for the ATM line used by the
Expand-over-ATM line-handler process at the remote system. This is the ATM
address you identified in Identifying the ATM Address Configured for the Remote
ATM Line on page 9-7. The last byte of this ATM address must be the selector byte
you obtained for the remote ATM line as described in Obtaining Selector Bytes for
the Local and Remote ATM Lines on page 9-6. The address must be preceded by
the characters ISONSAP:%H and must be enclosed in parentheses. For example:
(ISONSAP:%H47000580FFE1000000F21A29EB0000000001B381)
This modifier is only applicable to Expand-over-ATM line-handler processes that
use SVC connections.
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 through 254) of the system
connected to the other end of the line. If you do not specify the NEXTSYS modifier,
it defaults to an invalid value (255), and an operator message occurs during the
initialization of the Expand-over-ATM line-handler process. The path will not be
operational until you alter the NEXTSYS modifier to a valid value using either the
WAN subsystem SCF ALTER DEVICE command or the Expand subsystem SCF
ALTER PATH command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this Expand line-handler process.
Modifier names in the PEXQSATM profile are listed in Profile Modifiers on
page 9-17.
Expand Configuration and Management Manual—523347-008
9- 15
Configuring Expand-Over-ATM Lines
Considerations
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXQSATM profile are
described in Profile Modifiers on page 9-17.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Examples
In the following example, a device named $ATMLIN1 is created for a single-line
Expand-over-ATM line-handler process that uses a permanent virtual circuit (PVC)
connection.
-> ADD DEVICE $ZZWAN.#ATMLIN1, PROFILE SLHATM, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), RSIZE 0, &
PATHTF 3, NEXTSYS 251, ASSOCIATEDEV $ATM1, &
ASSOCIATESUBDEV #IP, CALLTYPE_PVC, PVCNAME PVC01
In the next example, the same device is created as part of a multi-CPU path. The
SUPERPATH_ON and L4EXTPACKETS_ON modifiers are required for line-handler
processes that are part of a multi-CPU path. The L4CONGCTRL_ON modifier is
recommended for Expand line-handler processes that are part of a multi-CPU path.
-> ADD DEVICE $ZZWAN.#ATMLIN1, PROFILE SLHATM, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), RSIZE 0, &
PATHTF 3, NEXTSYS 251, ASSOCIATEDEV $ATM1, &
ASSOCIATESUBDEV #IP, CALLTYPE_PVC, PVCNAME PVC01, &
14EXTPACKETS_ON, 14CONGCTRL_ON, SUPERPATH_ON
In the next example, a device named ATMLIN2 is created for a single-line Expandover-ATM line-handler process that uses an SVC connection.
-> ADD DEVICE $ZZWAN.#ATMLIN2, PROFILE SLHATM, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), RSIZE 0, &
PATHTF 3, NEXTSYS 251, ASSOCIATEDEV $ATM2, &
ASSOCIATESUBDEV #IP, CALLTYPE_SVC, ATMSEL 0, DESTATMADDR &
(ISONSAP:%H47000580FFE1000000F21A29EB0000000001B3)
Expand Configuration and Management Manual—523347-008
9- 16
Configuring Expand-Over-ATM Lines
Step 4: Start the Line-Handler Process
In the last example, a device named ATMLIN3 is created for a single-line Expand-overATM line-handler process that uses an ATMSAP connection through the SLSA
subsystem.
-> ADD DEVICE $ZZWAN.#ATMLIN3, PROFILE SLHATM, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), RSIZE 0, &
PATHTF 3, NEXTSYS 251, CALLTYPE_ATMSAP, LIFNAME LIF01
Step 4: Start the Line-Handler Process
To start a single-line Expand-over-ATM line-handler process, use the WAN subsystem
SCF START DEVICE command. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the Expand-over-ATM
line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Step 5: Start the Line
To start an Expand-over-ATM line, use the Expand subsystem SCF START LINE
command. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-ATM line-handler process.
The successful completion of this command leaves the line in the STARTED state.
Profile Modifiers
This subsection lists the recommended modifiers for single-line Expand-over-ATM
line-handler processes and describes the modifiers provided for configuring special
features. It also describes default values and value ranges for all the modifiers
contained in the PEXQSATM profile.
Note. A different profile is provided for Expand-over-ATM lines that are part of a multi-line
path; this profile is described in Section 14, Configuring Multi-Line Paths.
Expand Configuration and Management Manual—523347-008
9- 17
Configuring Expand-Over-ATM Lines
Recommended Modifiers
Recommended Modifiers
Recommended modifiers are modifiers that should be used to obtain optimum
performance and efficiency.
L4CONGCTRL_ON
Default:
Units:
Range:
ON
Not applicable
ON or OFF
This modifier enables the congestion control mechanism. Because data transfer with
the UDP is not guaranteed, the Expand End-to-End protocol is used to achieve reliable
communications for Expand-over-ATM connections. You can avoid congestion and
improve error recovery by using the L4CONGCTRL_ON modifier. The
L4CONGCTRL_ON modifier is also recommended for Expand line-handler processes
that are part of a multi-CPU path.
You should read the description of the congestion control feature in Section 18,
Subsystem Description, before using this modifier. The L4CONGCTRL_ON modifier is
described in detail in Section 17, Expand Modifiers.
PATHPACKETBYTES n
Default:
Units:
Range:
1024
Bytes
0 or 1024 through 9180 (9180 is recommended)
This modifier enables the variable packet size feature and specifies the maximum size,
in bytes, of a variable packet. PATHPACKETBYTES can be used on Expand-over-ATM
lines to increase the size of frames transmitted between neighboring nodes.
You should read the description of the variable packet size feature in Section 18,
Subsystem Description, before using this modifier. The PATHPACKETBYTES modifier
is described in detail in Section 17, Expand Modifiers.
L4EXTPACKETS_ON
Default:
Units:
Range:
ON
Not applicable
ON or OFF
This modifier is required for the variable packet size and congestion control features
(see L4CONGCTRL_ON and PATHPACKETBYTES n above). It is also required for
Expand line-handler processes that are part of multi-CPU path. The
L4EXTPACKETS_ON modifier is described in detail in Section 17, Expand Modifiers.
Expand Configuration and Management Manual—523347-008
9- 18
Modifiers for Special Features
Configuring Expand-Over-ATM Lines
Modifiers for Special Features
In addition to the L4CONGCTRL_ON and PATHPACKETBYTES modifiers, the
SUPERPATH_ON modifier is provided in the PEXQSATM profile to enable you to
configure the Expand multi-CPU feature.
For configuration considerations for all special features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of each feature,
refer to Section 3, Planning a Network Design.
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
PEXQSATM Modifiers
The disk file $SYSTEM.SYSnn.PEXQSATM defines modifiers for single-line Expandover-ATM line-handler processes.
Table 9-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile by default.
For a complete description of the modifiers listed in this table, refer to Section 17,
Expand Modifiers.
Table 9-1. PEXQSATM Modifiers for Expand-over-ATM Lines (page 1 of 3)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
None
Any 8-character string
ATMSEL2
%H80
0 through %HFF
CALLTYPE_PVC3
3
CALLTYPE_SVC2
CALLTYPE_ATMSAP4
COMPRESS_OFF7
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
DESTATMADDR 2
(ISONSAP:
%H00...)
Any valid 20-byte ISO
NSAP ATM address
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
EXTMEMSIZE
2048
0 through 32767
FRAMESIZE
132
64 through 2047
Expand Configuration and Management Manual—523347-008
9- 19
PEXQSATM Modifiers
Configuring Expand-Over-ATM Lines
Table 9-1. PEXQSATM Modifiers for Expand-over-ATM Lines (page 2 of 3)
Modifier
Default Value
Range of Values
L2RETRIES
20
1 through 255
L4CONGCTRL_OFF
L4CONGCTRL_ON
3
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LIFNAME5
None
Any 8-character string
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS5
255
0 to 254
OSSPACE
32767
3072 to 32767
OSTIMEOUT
300
10 to 32767
PATHBLOCKBYTES6
0
0 through 9152 or 9180
(0 is recommended)
PATHPACKETBYTES
1024
0 through 9180
(9180 is recommended)
PATHTF
0
0 through 186
PVCNAME3
None
Any 8-character string
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60
0 to 77600 (12hrs)
RETRYPROBE
19
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
3
SUPERPATH_ON
TIMERPROBE
1
1 through 32767
Expand Configuration and Management Manual—523347-008
9- 20
PEXQSATM Modifiers
Configuring Expand-Over-ATM Lines
Table 9-1. PEXQSATM Modifiers for Expand-over-ATM Lines (page 3 of 3)
Modifier
Default Value
Range of Values
TIMERRECONNECT
30
30 through 32767
TXWINDOW
7
2 through 25
1. This is a required modifier.
2. This modifier is required for Expand-over-ATM line-handler processes that use SVC connections.
3. This modifier is required for Expand-over-ATM line-handler processes that use PVC connections.
4. This modifier is required for Expand-over-ATM line-handler processes that use ATMSAP connections.
5. This is a required modifier. The default value is invalid and must be changed.
6. The maximum value is actually 9180, but for performance it is best to use whole multiples of 32, which would
result in a 9152 maximum.
7. Although the default value is COMPRESS_ON, we recommend that you turn it off for ATM.
Expand Configuration and Management Manual—523347-008
9- 21
Configuring Expand-Over-ATM Lines
Expand Configuration and Management Manual—523347-008
9- 22
PEXQSATM Modifiers
10
Configuring Expand-Over-X.25 Lines
X.25 is a standard for private and public networks that use packet-switching
technology. Expand-over-X.25 connections are provided by the HP X.25 Access
Method (X25AM) product. The Expand-over-X.25 line-handler process uses the
NETNAM protocol to access the network access method (NAM) interface provided by
an X25AM line-handler process.
An Expand-over-X.25 line-handler process can be configured as a single line, as part
of a multi-line path, or as part of a multi-CPU path. This section explains how to
configure an Expand-over-X.25 line-handler process as a single-line or as part of a
multi-CPU path. Configuring Expand-over-X.25 lines that are part of a multi-line path is
explained in Section 14, Configuring Multi-Line Paths.
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-X.25 line-handler process to provide Expand-over-X.25 connectivity. These
components are illustrated in Figure 10-1 and are explained in the following
subsections.
Expand Configuration and Management Manual—523347-008
10- 1
Required Hardware and Software
Configuring Expand-Over-X.25 Lines
Figure 10-1. Expand-Over-X.25 Line-Handler Process Components
Processor
Expand-over-X.25
Line-Handler
Process
NAM
X25AM LineHandler Process
File-System
Interface
QIO Shared
Memory
Segment
WAN
Shared
Driver
TCP/IP
Process
LAN Driver and Interrupt Handlers
(DIHs)
Y-Fabric
X-Fabric
LAN
Adapter
LAN
Adapter
SWAN
SWAN
VST004
Expand Configuration and Management Manual—523347-008
10- 2
Configuring Expand-Over-X.25 Lines
X25AM Line-Handler Process
X25AM Line-Handler Process
The Expand-over-X.25 line-handler process uses the services of an X25AM
line-handler process to provide access to X.25 packet-switched data networks
(PSDNs). Each X25AM line-handler process controls a single data communications
line and supports both permanent virtual circuits (PVCs) and switched virtual circuits
(SVCs). The X25AM line-handler process associated with the Expand-over-X.25
line-handler process must be configured and started before the Expand-over-X.25
line-handler process can begin exchanging data over an X.25 connection.
For information about configuring X25AM line-handler processes, refer to the X25AM
Configuration and Management Manual.
Note. You must obtain a subscription to an X.25 value-added network (VAN) or have access to
a dedicated X.25 network, to use an X.25 connection.
QIO Subsystem
QIO is a mechanism for transferring data between processes through a shared
memory segment. The QIO subsystem is preconfigured and started during the system
load sequence. The QIO subsystem must be started and running before Expand
line-handler processes can be started.
For information about the QIO subsystem, refer to the QIO Configuration and
Management Manual.
Wide Area Network (WAN) Shared Driver
The WAN shared driver is a set of library procedures that is bound with each inputoutput process (IOP) that uses a ServerNet wide area network (SWAN) concentrator.
The WAN shared driver is a component of the WAN subsystem. The WAN subsystem
is preconfigured and started during the system load sequence.
For information about the WAN subsystem, refer to the WAN Subsystem Configuration
and Management Manual.
NonStop TCP/IP Process
The NonStop TCP/IP subsystem provides TCP/IP data communications connectivity.
NonStop TCP/IP processes are used by the following LAN adapters: Ethernet 4
ServerNet adapters (E4SAs), Fast Ethernet ServerNet adapters (FESAs), Gigabit
Ethernet ServerNet adapters (GESAs), Gigabit Ethernet 4-port ServerNet adapters
(G4SAs), and SWAN concentrators. The NonStop TCP/IP processes that support the
E4SAs, FESAs, GESAs, G4SAs, and SWAN concentrators are preconfigured and
started during the system load sequence.
For information about the NonStop TCP/IP, Parallel Library TCP/IP, and NonStop
TCP/IPv6 subsystems, refer to the TCP/IPv6 Configuration and Management Manual,
Expand Configuration and Management Manual—523347-008
10- 3
Configuring Expand-Over-X.25 Lines
Local Area Network (LAN) Driver and Interrupt
Handlers (DIHs)
the TCP/IP (Parallel Library) Configuration and Management Manual, and the
TCP/IPv6 Configuration and Management Manual.
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
NonStop TCP/IP processes can interface to the network through the ServerNet LAN
Systems Access (SLSA) subsystem. The SLSA subsystem provides QIO-based driver
and interrupt handlers (DIHs) that allow NonStop TCP/IP processes to connect to a
LAN adapter. The SLSA subsystem is preconfigured and started during the system
load sequence.
For information about the SLSA subsystem, refer to the LAN Configuration and
Management Manual.
Ethernet 4 ServerNet Adapter (E4SA)
The E4SA is a double-high ServerNet adapter that supports four Ethernet interfaces
and communicates with multiple processors through its dual ServerNet interfaces to
the ServerNet fabrics. Two E4SAs are used to connect a SWAN concentrator to a
processor. For information about the E4SA, refer to the LAN Configuration and
Management Manual.
Fast Ethernet ServerNet Adapter (FESA)
The FESA is a single-port adapter that provides connectivity between NonStop
S-series servers and Fast Ethernet 802.3u LANs. The data transfer rate is limited to 10
Mbps when the FESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the FESA is connected to a SWAN 2 concentrator. For
information about FESAs, refer to the LAN Configuration and Management Manual.
Gigabit Ethernet ServerNet Adapter (GESA)
The Gigabit Ethernet ServerNet adapter (GESA) is a single-port ServerNet adapter
that provides Gigabit connectivity between NonStop S-series systems and Ethernet
LANs. A GESA can be directly installed in slots 51 through 54 of an I/O enclosure and
slots 53 and 54 of a processor enclosure. The data transfer rate is limited to 10 Mbps
when the GESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the GESA is connected to a SWAN 2 concentrator. For
information about the GESA, refer to the LAN Configuration and Management Manual.
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA)
The Gigabit Ethernet 4-port ServerNet adapter (G4SA) is a multiport ServerNet
adapter that provides Gigabit connectivity between NonStop S-series systems and
Ethernet LANs. A G4SA can be directly installed in slots 1 through 5 of an I/O adapter
module (IOAM). Since there are two IOAMs in an IOAM enclosure, a total of 10 G4SAs
can be installed in an enclosure. The G4SA replaces the Ethernet 4 ServerNet adapter
(E4SA), Fast Ethernet ServerNet adapter (FESA), and the Gigabit Ethernet ServerNet
Expand Configuration and Management Manual—523347-008
10- 4
Configuring Expand-Over-X.25 Lines
ServerNet Wide Area Network (SWAN) Concentrator
adapter (GESA). The G4SA is the only LAN adapter supported for the IOAM
enclosure, and it cannot be installed in a NonStop S-series enclosure. The data
transfer rate is limited to 10 Mbps when the G4SA is connected to a SWAN
concentrator, but a data transfer rate of 10/100 Mbps is possible when the G4SA is
connected to a SWAN 2 concentrator. For information about the G4SA, refer to the
LAN Configuration and Management Manual.
ServerNet Wide Area Network (SWAN) Concentrator
The SWAN concentrator is a communications device that provides wide area network
(WAN) connections. HP recommends that you configure the SWAN concentrator in the
same processor pair as the Expand line-handler processes.
For information about the SWAN concentrator, refer to the WAN Subsystem
Configuration and Management Manual.
Topology Considerations
An Expand-over-X.25 network must be configured as a logical fully connected mesh. In
a single-line path configuration, you configure one Expand-over-X.25 line-handler
process for each destination node in the network. In a multi-CPU configuration, you
configure multiple Expand-over-X.25 line-handler processes, usually in separate
processors, for each destination node in the network. In a multi-line path configuration,
you configure a path that consists of multiple lines between the source and destination
nodes.
In Figure 10-2, a single-line path is configured between node \A and node \C; a multiCPU path that consists two paths is configured between node \A and node \B; and a
multi-line path that consists of three lines is configured between node \B and node \C.
Expand Configuration and Management Manual—523347-008
10- 5
Topology Considerations
Configuring Expand-Over-X.25 Lines
Figure 10-2. Expand-Over-X.25 Line-Handler Process Topology
Node \A
CPU 0
LH
CPU 1
CPU 2
Single-Line Path
LH
LH
Node \C
CPU 0
Multi-CPU
Path
PSDN
LH
LH
LH
CPU 0
LH
CPU 1
CPU 2
Multiline Path
LH
Node \B
Key
Configured Path
CDT 043.CDD
Expand Configuration and Management Manual—523347-008
10- 6
Summary of Configuration Steps
Configuring Expand-Over-X.25 Lines
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 10-1 for details), configuring and starting a single-line
Expand-over-X.25 line-handler process involves the following steps.
Step
Tool Used
Step 1: Add a NAM Subdevice to the X25AM Line
SCF interface to the X25AM
subsystem
Step 2: Start the X25AM Line
SCF interface to the X25AM
subsystem
Step 3: Create a Profile for the Expand-Over-X.25 LineHandler Process
SCF interface to the WAN
subsystem
Step 4: Create the Expand-Over-X.25 Line-Handler
Process
SCF interface to the WAN
subsystem
Step 5: Start the Expand-Over-X.25 Line-Handler Process
SCF interface to the WAN
subsystem
Step 6: Start the Expand-Over-X.25 Line
SCF interface to the Expand
subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure
Expand-over-X.25 line-handler processes; it is not meant to show the complete syntax of the
SCF commands described. Refer to the following manuals for more information:
•
•
•
X25AM Configuration and Management Manual for X25AM subsystem SCF commands
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Step 1: Add a NAM Subdevice to the X25AM
Line
Note. The following procedure assumes that an X25AM line-handler process has already
been created. To create an such a process, you must add it as a device to the WAN
subsystem. For complete information about creating X25AM processes, refer to the WAN
Subsystem Configuration and Management Manual.
An Expand-over-X.25 line-handler process must have access to a NAM subdevice of
an X25AM line. You use the X25AM subsystem SCF ADD SU command to configure a
NAM subdevice. For example, the following command creates a NAM subdevice
named #XNAM for an X25AM line named $X2501:
-> ADD SU $X2501.#XNAM, PROTOCOL NAM, DEVTYPE (63,0), &
RECSIZE 128, DESTADDR "3012233490", port 90
Expand Configuration and Management Manual—523347-008
10- 7
Configuring Expand-Over-X.25 Lines
Considerations
For more information, refer to the X25AM Configuration and Management Manual.
Considerations
The following configuration considerations apply to SU objects:
•
•
•
The PROTOCOL attribute identifies the protocol that will be used by the subdevice.
Subdevices used by Expand-over-X.25 line-handler processes must use the
NETNAM protocol (specified by the argument NAM).
The DEVTYPE attribute specifies the subdevice type. The subdevice type for NAM
subdevices is 63,0.
The RECSIZE attribute specifies the record size for records transmitted and
received by the subdevice. You should set RECSIZE equal to the Expand packet
size.
Step 2: Start the X25AM Line
Before you can start the Expand-over-X.25 line, the X25AM line must be started. (The
NAM subdevice is started automatically when it is added.)
You use the X25AM subsystem SCF START LINE command to start an X25AM line.
For example, the following command starts an X25AM line-handler process named
$X2501:
-> START LINE $x2501
Step 3: Create a Profile for the Expand-OverX.25 Line-Handler Process
You can create a profile for a single-line Expand-over-X.25 line-handler process using
the PEXQSNAM profile. This profile is provided in the $SYSTEM.SYSnn subvolume.
You can also create a new profile from an existing profile, or you can create your own
profile. For complete information about profiles, refer to the WAN Subsystem
Configuration and Management Manual.
This subsection describes how to create a profile using PEXQSNAM.
Note. Different profiles are provided for Expand-over-X.25 lines that are part of a multi-line
path; these profiles are described in Section 14, Configuring Multi-Line Paths.
Expand Configuration and Management Manual—523347-008
10- 8
Configuring Expand-Over-X.25 Lines
ADD Profile Command
ADD Profile Command
To create a profile from the PEXQSNAM profile template, use the WAN subsystem
SCF ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to 8 alphanumeric
characters that will be used to identify the new profile. You will reference this
profile_name when you create a device for the line-handler process in Step 4:
Create the Expand-Over-X.25 Line-Handler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSNAM is the disk filename of the profile provided for Expand-overNAM line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSNAM
profile are listed in Profile Modifiers on page 10-13.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSNAM profile are described in Profile Modifiers on page 10-13.
Example
In the following example, a profile named SLHX25 is created for a single-line Expandover-X.25 line-handler process using the PEXQSNAM profile. The COMPRESS_OFF
modifier is added to the profile.
-> ADD PROFILE $ZZWAN.#SLHX25, FILE $SYSTEM.SYS01.PEXQSNAM, &
COMPRESS_OFF
Expand Configuration and Management Manual—523347-008
10- 9
Configuring Expand-Over-X.25 Lines
Step 4: Create the Expand-Over-X.25 Line-Handler
Process
Step 4: Create the Expand-Over-X.25
Line-Handler Process
You create a single-line Expand-over-X.25 line-handler process by adding it as a
device to the WAN subsystem.
Note. This section explains how to configure single-line Expand-over-X.25 line-handler
processes only. Creating Expand-over-X.25 lines that are part of a multi-line path is explained
in Section 14, Configuring Multi-Line Paths.
ADD DEVICE Command
To create a single-line Expand-over-X.25 line-handler process, use the WAN
subsystem SCF ADD DEVICE command. The command syntax is as follows:
ADD
,
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,0)
RSIZE rsize
ASSOCIATEDEV $nam_process
ASSOCIATESUBDEV #subdevice
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand line-handler
process to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for this Expand line-handler process in Step
3: Create a Profile for the Expand-Over-X.25 Line-Handler Process.
CPU cpunumber
indicates the processor where this Expand line-handler process will normally
execute.
Expand Configuration and Management Manual—523347-008
10 -10
Configuring Expand-Over-X.25 Lines
ADD DEVICE Command
ALTCPU altcpunumber
indicates the processor where the backup Expand line-handler process will
normally execute.
TYPE (63,0)
is the device type and subtype for this Expand line-handler process. The device
type is always 63 for Expand line-handler processes. The subtype is 0 for singleline Expand-over-X.25 line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ASSOCIATEDEV nam_process
specifies the device name of the X25AM line-handler process you want to
associate with this Expand-over-X.25 line-handler process.
ASSOCIATESUBDEV subdevice
is a required modifier that specifies the name of the X25AM subdevice to which the
Expand-over-X.25 line-handler process will bind. subdevice is a NAM subdevice
defined for the X25AM line used by the Expand-over-X.25 line-handler process.
Adding a subdevice is explained in Step 1: Add a NAM Subdevice to the X25AM
Line on page 10-7.
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 to 254) of the system
connected to the other end of the line. If you do not specify NEXTSYS, this
modifier defaults to an invalid value (255), and an operator message occurs during
the initialization of the Expand-over-X.25 line-handler process. The path will not be
operational until you alter NEXTSYS to a valid value using either the WAN
subsystem SCF ALTER DEVICE command, or the Expand subsystem SCF ALTER
PATH command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this Expand line-handler process.
Modifier names in the PEXQSNAM profile are listed in Profile Modifiers on
page 10-13.
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this Expand line-handler process.
Expand Configuration and Management Manual—523347-008
10 -11
Configuring Expand-Over-X.25 Lines
Considerations
Default values and ranges of values for modifiers in the PEXQSNAM profile are
described in Profile Modifiers on page 10-13.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Examples
In the following example, a device named $EXPSL3 is created for a single-line
Expand-over-X.25 line-handler process. $EXPSL3 will bind to a NAM subdevice
named #XNAM on the X25AM line-handler process named $X2501. The L4TIMEOUT
modifier is recommended for Expand-over-X.25 line-handler processes.
-> ADD DEVICE $ZZWAN.#EXPS13, PROFILE SLHX25, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 31, ASSOCIATEDEV $X2501, &
ASSOCIATESUBDEV #XNAM, 14TIMEOUT 3000
In the next example, the same device is created as part of a multi-CPU path. The
SUPERPATH_ON and L4EXTPACKETS_ON modifiers are required for line-handler
processes that are part of a multi-CPU path. The L4CONGCTRL_ON modifier is
recommended for Expand line-handler processes that are part of a multi-CPU path.
-> ADD DEVICE $ZZWAN.#EXPS13, PROFILE SLHX25, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 31, ASSOCIATEDEV $X2501, &
ASSOCIATESUBDEV #XNAM, 14TIMEOUT 3000, 14EXTPACKETS_ON, &
14CONGCTRL_ON, SUPERPATH_ON
Step 5: Start the Expand-Over-X.25
Line-Handler Process
To start a single-line Expand-over-X.25 line-handler process, use the WAN subsystem
SCF START DEVICE command. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the Expand-over-X.25
line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Expand Configuration and Management Manual—523347-008
10 -12
Configuring Expand-Over-X.25 Lines
Step 6: Start the Expand-Over-X.25 Line
Step 6: Start the Expand-Over-X.25 Line
To start an Expand-over-X.25 line, use the Expand subsystem SCF START LINE
command. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-X.25 line-handler process.
The successful completion of this command leaves the line in the STARTED state.
Profile Modifiers
This subsection lists the recommended modifiers for Expand-over-X.25 line-handler
processes and describes the modifiers provided for configuring special features. It also
describes default values and value ranges for all the modifiers contained in the
PEXQSNAM profile.
Note. A different profile is provided for Expand-over-X.25 lines that are part of a multi-line
path; this profile is described in Section 14, Configuring Multi-Line Paths.
Recommended Modifiers
Recommended modifiers are modifiers that should be used to obtain optimum
performance and efficiency. The following modifier is recommended for Expand-overX.25 line-handler processes:
L4TIMEOUTn
Default:
Units:
Range:
2000 (20 seconds)
0.01 seconds
500 through 32,767 (5.00 seconds through 5.27.67 minutes)
This modifier specifies the time interval, in one-hundredth of a second increments, that
the Expand-over-X.25 line-handler process will wait for a response to an end-to-end
(Layer 4) request before retrying. L4TIMEOUT should be the same for every Expand
line-handler process in the network.
If a message is not acknowledged within the L4TIMEOUT period, an enquiry (ENQ) will
be initiated. Because retransmissions of an X.25 network can degrade response time,
cause network link congestion, or result in excessive packet charges, you should set
L4TIMEOUT to a value in excess of the maximum anticipated response time on a
loaded link.
Note. The Expand End-to-End protocol is explained in Path Function of the Expand
Subsystem on page 18-13.
Expand Configuration and Management Manual—523347-008
10 -13
Configuring Expand-Over-X.25 Lines
Modifiers for Special Features
Modifiers for Special Features
The following modifiers are provided in the PEXQSNAM profile to enable you to
configure special features:
•
•
•
•
PATHBLOCKBYTES modifier for the multipacket frame feature
PATHPACKETBYTES modifier for the variable packet size feature
L4CONGCTRL_ON modifier for the congestion control feature
SUPERPATH_ON modifier for the Expand multi-CPU feature
For configuration considerations for these features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of these
features, refer to Section 3, Planning a Network Design.
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
X25AM Line-Handler Process Modifiers
You might need to set the following X25AM modifier when configuring an X25AM
line-handler process that will be accessed by an Expand-over-X.25 line-handler
process. This modifier is described in detail in the X25AM Configuration and
Management Manual.
L3WINDOWn
Default:
Units:
Range:
2
Packets
1 through 15 (L3MOD128), 1 through 7 (L3MOD8)
This modifier specifies the number of packets that can be outstanding without an
acknowledgment from the network. You should set L3WINDOW to the largest possible
value.
Note. Some X.25 networks limit the size of L3WINDOW. Consult your vendor for more
information.
PEXQSNAM Modifiers
The disk file $SYSTEM.SYSnn.PEXQSNAM defines modifiers for Expand-over-X.25
line-handler processes.
Table 10-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Expand Configuration and Management Manual—523347-008
10 -14
PEXQSNAM Modifiers
Configuring Expand-Over-X.25 Lines
Table 10-1. PEXQSNAM Modifiers for Expand-over-X.25 Lines (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
Any 8-character string
ASSOCIATESUBDEV1
Any 8-character string
COMPRESS_OFF
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
EXTMEMSIZE
2048
0 through 32767
FRAMESIZE
132
64 through 2047
L2RETRIES
10
1 through 255
L4CONGCTRL_OFF
3
ON or OFF
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS2
255
0 through 254
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0
0 through 186
RETRYPROBE
20
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
3
Expand Configuration and Management Manual—523347-008
10 -15
PEXQSNAM Modifiers
Configuring Expand-Over-X.25 Lines
Table 10-1. PEXQSNAM Modifiers for Expand-over-X.25 Lines (page 2 of 2)
Modifier
Default Value
Range of Values
TIMERINACTIVITY
900
0 through 32767
TIMERPROBE
300
1 through 32767
TIMERRECONNECT
30
0 through 32767
TXWINDOW
4
2 through 7
SUPERPATH_ON
1. This is a required modifier. It has no default value.
2. This is a required modifier. The default value is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
10 -16
11
Configuring Expand-Over-SNA Lines
Systems Network Architecture (SNA) was developed by IBM for connecting IBM
systems and networks. Expand-over-SNA connections are provided with the HP
SNAX/Advanced Peer Networking (SNAX/APN) product. The Expand-over-SNA
line-handler process uses the NETNAM protocol to access the network access method
(NAM) interface provided by a SNAX/APN line-handler process.
An Expand-over-SNA line-handler process can be configured as a single line, as part
of a multi-line path, or as part of a multi-CPU path. This section explains how to
configure an Expand-over-SNA line-handler process as a single line or as part of a
multi-CPU path. Configuring Expand-over-SNA lines that are part of a multi-line path is
explained in Section 14, Configuring Multi-Line Paths.
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-SNA line-handler process to provide Expand-over-SNA connectivity. These
components are illustrated in Figure 11-1 and are explained in the following
subsections.
Expand Configuration and Management Manual—523347-008
11-1
Required Hardware and Software
Configuring Expand-Over-SNA Lines
Figure 11-1. Expand-Over-SNA Line-Handler Process Components
Processor
Expand-overSNA LineHandler Process
NAM
SNAX/APN
Line-Handler
Process
File-System
Interface
QIO Shared
Memory
Segment
WAN
Shared
Driver
TCP/IP
Process
LAN Driver and Interrupt Handlers
(DIHs)
Y-Fabric
X-Fabric
LAN
Adapter
LAN
Adapter
SWAN
SWAN
VST005
Expand Configuration and Management Manual—523347-008
11- 2
Configuring Expand-Over-SNA Lines
SNAX/APN Line-Handler Process
SNAX/APN Line-Handler Process
The Expand-over-SNA line-handler process uses the services of a SNAX/APN
line-handler process to provide access to an IBM SNA network. The SNA network can
be a traditional network of host mainframes and front end processors, an advanced
peer-to-peer network of AS400 systems or other workstations, or a mix of these types
of networks.
Each Expand-over-SNA line-handler process must be configured to use a particular
SNAX/APN line and logical unit (LU). At least one SNAX/APN line-handler process and
one Expand line-handler process must be configured and started at each end of the
SNA network through which the Expand-over-SNA line-handler process will
communicate. A SNAX/APN line and an associated LU must be configured and started
before the Expand-over-SNA line-handler process can begin exchanging data over an
SNA network.
For information about creating SNAX/APN line-handler processes, refer to the WAN
Subsystem Configuration and Management Manual. For information about adding
SNAX/APN lines and LUs, refer to the SNAX/XF and SNAX/APN Configuration and
Management Manual.
QIO Subsystem
QIO is a mechanism for transferring data between processes through a shared
memory segment. The QIO subsystem is preconfigured and started during the system
load sequence. The QIO subsystem must be started and running before Expand
line-handler processes can be started.
For information about the QIO subsystem, refer to the QIO Configuration and
Management Manual. For information about how the WAN subsystem uses QIO, refer
to the WAN Subsystem Configuration and Management Manual.
Wide Area Network (WAN) Shared Driver
The WAN shared driver is a set of library procedures that is bound with each inputoutput process (IOP) that uses a ServerNet wide area network (SWAN) concentrator.
The WAN shared driver is a component of the WAN subsystem. The WAN subsystem
is preconfigured and started during the system load sequence.
For information about the WAN subsystem, refer to the WAN Subsystem Configuration
and Management Manual.
Expand Configuration and Management Manual—523347-008
11- 3
Configuring Expand-Over-SNA Lines
NonStop TCP/IP Process
NonStop TCP/IP Process
The NonStop TCP/IP subsystem provides TCP/IP data communications connectivity.
NonStop TCP/IP processes are used by the following LAN adapters: Ethernet 4
ServerNet adapters (E4SAs), Fast Ethernet ServerNet adapters (FESAs), Gigabit
Ethernet ServerNet adapters (GESAs), Gigabit Ethernet 4-port ServerNet adapters
(G4SAs), and SWAN concentrators. The NonStop TCP/IP processes that support the
E4SAs, FESAs, GESAs, G4SAs and SWAN concentrators are preconfigured and
started during the system load sequence.
For information about the NonStop TCP/IP, Parallel Library TCP/IP, and NonStop
TCP/IPv6 subsystems, refer to the TCP/IPv6 Configuration and Management Manual,
the TCP/IP (Parallel Library) Configuration and Management Manual, and the
TCP/IPv6 Configuration and Management Manual.
Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)
NonStop TCP/IP processes can interface to the network through the ServerNet LAN
Systems Access (SLSA) subsystem. The SLSA subsystem provides QIO-based driver
and interrupt handlers (DIHs) that allow NonStop TCP/IP processes to connect to a
LAN adapter. The SLSA subsystem is preconfigured and started during the system
load sequence.
For information about the SLSA subsystem, refer to the LAN Configuration and
Management Manual.
Ethernet 4 ServerNet Adapter (E4SA)
The E4SA is a double-high ServerNet adapter that supports four Ethernet interfaces
and communicates with multiple processors through its dual ServerNet interfaces to
the ServerNet fabrics. Two E4SAs are used to connect a SWAN concentrator to a
processor. For information about the E4SA, refer to the LAN Configuration and
Management Manual.
Fast Ethernet ServerNet Adapter (FESA)
The FESA is a single-port adapter that provides connectivity between NonStop
S-series servers and Fast Ethernet 802.3u LANs. The data transfer rate is limited to 10
Mbps when the FESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the FESA is connected to a SWAN 2 concentrator. For
information about FESAs, refer to the LAN Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
11- 4
Configuring Expand-Over-SNA Lines
Gigabit Ethernet ServerNet Adapter (GESA)
Gigabit Ethernet ServerNet Adapter (GESA)
The Gigabit Ethernet ServerNet adapter (GESA) is a single-port ServerNet adapter
that provides Gigabit connectivity between NonStop S-series systems and Ethernet
LANs. A GESA can be directly installed in slots 51 through 54 of an I/O enclosure and
slots 53 and 54 of a processor enclosure. The data transfer rate is limited to 10 Mbps
when the GESA is connected to a SWAN concentrator, but a data transfer rate of
10/100 Mbps is possible when the GESA is connected to a SWAN 2 concentrator. For
information about the GESA, refer to the LAN Configuration and Management Manual.
Gigabit Ethernet 4-Port ServerNet Adapter (G4SA)
The Gigabit Ethernet 4-port ServerNet adapter (G4SA) is a multiport ServerNet
adapter that provides Gigabit connectivity between NonStop S-series systems and
Ethernet LANs. A G4SA can be directly installed in slots 1 through 5 of an I/O adapter
module (IOAM). Since there are two IOAMs in an IOAM enclosure, a total of 10 G4SAs
can be installed in an enclosure. The G4SA replaces the Ethernet 4 ServerNet adapter
(E4SA), Fast Ethernet ServerNet adapter (FESA), and the Gigabit Ethernet ServerNet
adapter (GESA). The G4SA is the only LAN adapter supported for the IOAM
enclosure, and it cannot be installed in a NonStop S-series enclosure. The data
transfer rate is limited to 10 Mbps when the G4SA is connected to a SWAN
concentrator, but a data transfer rate of 10/100 Mbps is possible when the G4SA is
connected to a SWAN 2 concentrator. For information about the G4SA, refer to the
LAN Configuration and Management Manual.
ServerNet Wide Area Network (SWAN) Concentrator
The SWAN concentrator is a communications device that provides wide area network
(WAN) connections. HP recommends that you configure the SWAN concentrator in the
same processor pair as the Expand line-handler processes.
For information about the SWAN concentrator, refer to the WAN Subsystem
Configuration and Management Manual.
Topology Considerations
An Expand-over-SNA network must be configured as a logical fully connected mesh. In
a single-line path configuration, you configure one Expand-over-SNA line-handler
process for each destination node in the network. In a multi-CPU configuration, you
configure multiple Expand-over-SNA line-handler processes, usually in separate
processors, for each destination node in the network. In a multi-line path configuration,
you configure a path that consists of multiple lines between the source and destination
nodes.
In Figure 11-2, a single-line path is configured between node \A and node \C; a multiCPU path that consists of two path is configured between node \A and node \B; and a
multi-line path that consists of three lines is configured between node \B and node \C.
Expand Configuration and Management Manual—523347-008
11- 5
Topology Considerations
Configuring Expand-Over-SNA Lines
Figure 11-2. Expand-Over-SNA Line-Handler Process Topology
Node \A
CPU 0
LH
CPU 1
CPU 2
Single-Line Path
LH
LH
Node \C
CPU 0
Multi-CPU
Path
SNA Network
LH
LH
LH
CPU 0
LH
CPU 1
CPU 2
Multiline Path
LH
Node \B
Key
Configured Path
CDT 044.CDD
Expand Configuration and Management Manual—523347-008
11- 6
Configuring Expand-Over-SNA Lines
Summary of Configuration Steps
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 11-1 for details), configuring and starting a single-line
Expand-over-SNA line-handler process involves the following steps:
Step
Tool Used
Step 1: Add the SNAX/APN Line
SCF interface to the
SNAX/APN subsystem
Step 2: Add the LUs for the SNAX/APN Line
SCF interface to the
SNAX/APN subsystem
Step 3: Start the SNAX/APN Line
SCF interface to the
SNAX/APN subsystem
Step 4: Create a Profile for the Expand-Over-SNA LineHandler Process
SCF interface to the WAN
subsystem
Step 5: Create the Expand-Over-SNA Line-Handler Process
SCF interface to the WAN
subsystem
Step 6: Start the Expand-Over-SNA Line-Handler Process
SCF interface to the WAN
subsystem
Step 7: Start the Expand-Over-SNA Line
SCF interface to the
Expand subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure
Expand-over-SNA line-handler processes; it is not meant to show the complete syntax of the
SCF commands described. Refer to the following manuals for more information:
•
•
•
SNAX/XF and SNAX/APN Configuration and Management Manual for SNAX/APN
subsystem commands
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Expand Configuration and Management Manual—523347-008
11- 7
Configuring Expand-Over-SNA Lines
Step 1: Add the SNAX/APN Line
Step 1: Add the SNAX/APN Line
Note. The following instructions assume that a SNAX/APN line-handler process has already
been created. To create such a process, you must add it as a device to the WAN subsystem.
For information about creating SNAX/APN line-handler processes, refer to the WAN
Subsystem Configuration and Management Manual.
At least one SNAX/APN line must be configured and started at each end of the SNA
network through which the Expand-over-SNA line-handler process will communicate.
You use the SNAX/APN subsystem SCF ADD LINE command to configure a
SNAX/APN line. For example, the following command creates a SNAX/APN line called
$SNAPA:
-> ADD LINE $SNAPA, RECSIZE 524, MAXPUS 1, MAXLUS 30, &
STATION PRIMARY, MAXLOCALLUS 10, POLLINT 0.01
For details about configuring SNAX/APN lines, refer to the SNAX/XF and SNAX/APN
Configuration and Management Manual. SCF ADD LINE attributes are also described
in the SNAX/XF and SNAX/APN Configuration and Management Manual.
Considerations
POLLINT should be set to the minimum value (0.01 seconds) on Synchronous Data
Link Control (SDLC) lines for best performance.
Step 2: Add the LUs for the SNAX/APN Line
You must configure a local and a remote logical unit (LU) for the SNAX/APN line. The
Expand-over-SNA line-handler process is configured to use a particular local LU.
You use the SNAX/APN subsystem SCF ADD LU command to add the local LU. For
example, the following command creates a local LU with a subdevice name of #LLUA
for the SNAX/APN line $SNAPA:
-> ADD LU $SNAPA.#LLUA, TYPE (14,21), SNANAME LUA, PROTOCOL NAM, &
DLUNAME #RLUA, RSPTYPE ER
Before you can add the remote LU, you must add a remote physical unit (PU); the
remote LU will be subordinate to this PU. You use the SNAX/APN SCF ADD PU
command to add a remote PU. For example, the following command creates a remote
PU with a subdevice name of #RPUA for the SNAX/APN line $SNAPA:
-> ADD PU $SNAPA.#RPUA, TYPE (13,21), ADDRESS %HC1, RECSIZE 521, &
MAXLUS 30
After you have created the remote PU, you use the SNAX/APN subsystem SCF ADD
LU command to add the remote LU. For example, the following command creates a
remote LU with a subdevice name of #RLUA for the SNAX/APN line $SNAPA:
-> ADD LU $SNAPA.#RLUA, TYPE (14,21), SNANAME LUB, PUNAME #RPUA
Expand Configuration and Management Manual—523347-008
11- 8
Configuring Expand-Over-SNA Lines
Considerations
For details about configuring LUs and PUs, and SCF ADD LU and ADD PU command
attributes, refer to the SNAX/XF and SNAX/APN Configuration and Management
Manual.
Considerations
The following configuration considerations apply to local LU object attributes:
•
•
•
The PROTOCOL attribute must be set to NAM.
The local SNANAME on one system must match the remote LU SNANAME on the
other system.
If the local LU is to initiate sessions, DLUNAME must be defined (matching the last
part of the remote LU object name). If the remote PU has DYNAMIC ON, remote
LUs will always be able to initiate sessions. However, DLUNAME must be specified
in one of the two systems in order for the connection to become active.
Example
Figure 11-3 shows the SCF commands used to configure a SNAX/APN line, local LU,
remote PU, and remote LU at two nodes in an Expand network.
Expand Configuration and Management Manual—523347-008
11- 9
Example
Configuring Expand-Over-SNA Lines
Figure 11-3. SNAX/APN Line Configuration Example
System \A
Expand
Line-Handler
Process
SNAX/APN
Line-Handler
Process
($SNAPA)
SWAN
SNA Network
SCF Commands for System \A
ADD LINE $SNAPA
, RECSIZE 524
, MAXPUS 1
, MAXLUS 30
, STATION PRIMARY
, MAXLOCALLUS 10
, POLLINT 0.01
ADD LU $SNAPA.#LLUA
, TYPE (14,21)
, SNANAME LUA
, PROTOCOL NAM
, DLUNAME #RLUA
, RSPTYPE ER
ADD PU $SNAPA.#RPUA
, TYPE (13,21)
, ADDRESS %HC1
, RECSIZE 521
, MAXLUS 30
ADD LU $SNAPA.#RLUA
, SNANAME LUB
, PUNAME #RPUA
Local LU DLUNAME
and remote LU
subdevice
name must match
SCF Commands for System \B
SWAN
SNAX/APN
Line-Handler
Process
($SNASB)
Expand
Line-Handler
Process
System \B
ADD LINE $SNASB
, RECSIZE 524
, MAXPUS 1
, MAXLUS 30
, STATION SECONDARY
, MAXLOCALLUS 10
ADD LU $SNASB.#LLUB
, TYPE (14,21)
, SNANAME LUB
, PROTOCOL NAM
, DLUNAME #RLUB
, RSPTYPE ER
ADD PU $SNASB.#RPUB
, TYPE (13,21)
, ADDRESS %HC1
, RECSIZE 521
, MAXLUS 30
ADD LU $SNASB.#RLUB
, SNANAME LUA
, PUNAME #RPUB
Local LU SNANAME
and remote LU
SNANAME
must match
Expand Configuration and Management Manual—523347-008
11 -10
CDT 050.CDD
Configuring Expand-Over-SNA Lines
Step 3: Start the SNAX/APN Line
Step 3: Start the SNAX/APN Line
Before you can start the Expand-over-SNA line, the SNAX/APN line (and its associated
PUs and LUs) must be started. To start a SNAX/APN line, use the SNAX/APN
subsystem SCF START LINE command. The following command starts a SNAX/APN
line named $SNAPA and its associated PUs and LUs:
-> START LINE $SNAPA, SUB ALL
For details about starting SNAX/APN lines, refer to the SNAX/XF and SNAX/APN
Configuration and Management Manual.
Step 4: Create a Profile for the Expand-OverSNA Line-Handler Process
You can create a profile for a single-line Expand-over-SNA line-handler process using
the PEXQSNAM profile. This profile is provided in the $SYSTEM.SYSnn subvolume.
You can also create a new profile from an existing profile, or you can create your own
profile. For complete information about profiles, refer to the WAN Subsystem
Configuration and Management Manual.
This subsection shows you how to create a profile using PEXQSNAM.
Note. Different profiles are provided for Expand-over-SNA lines that are part of a multi-line
path; these profiles are described in Section 14, Configuring Multi-Line Paths.
ADD Profile Command
To create a profile from the PEXQSNAM profile template, use the WAN subsystem
SCF ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create a device for the line-handler
process in Step 5: Create the Expand-Over-SNA Line-Handler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSNAM is the disk filename of the profile provided for Expand-overNAM line-handler processes.
Expand Configuration and Management Manual—523347-008
11 -11
Configuring Expand-Over-SNA Lines
Example
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSNAM
profile are listed in Profile Modifiers on page 11-16.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSNAM profile are described in Profile Modifiers on page 11-16.
Example
In the following example, a profile named SLHSNA is created for a single-line Expandover-SNA line-handler process using the PEXQSNAM profile. The
AFTERMAXRETRIES_DOWN is set in the profile.
-> ADD PROFILE $ZZWAN.#SLHSNA, FILE $SYSTEM.SYS01.PEXQSNAM, &
AFTERMAXRETRIES_DOWN
Step 5: Create the Expand-Over-SNA
Line-Handler Process
You create a single-line Expand-over-SNA line-handler process by adding it as a
device to the WAN subsystem.
Note. This section explains how to configure single-line Expand-over-SNA line-handler
processes only. Creating Expand-over-SNA lines that are part of a multi-line path is explained
in Section 14, Configuring Multi-Line Paths.
ADD DEVICE Command
To create a single-line Expand-over-SNA line-handler process, use the WAN
subsystem SCF ADD DEVICE command. The command syntax is as follows:
ADD DEVICE $ZZWAN.#device_name
, IOPOBJECT $SYSTEM.SYSnn.LHOBJ
, PROFILE profile_name
, CPU cpunumber
, ALTCPU altcpunumber
, TYPE (63,0 )
, RSIZE rsize
, ASSOCIATEDEV $nam_process
, ASSOCIATESUBDEV #subdevice
, NEXTSYS sys_number
[, modifier_keyword [ modifier_value ] ] ...
Expand Configuration and Management Manual—523347-008
11 -12
Configuring Expand-Over-SNA Lines
ADD DEVICE Command
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand line-handler
process to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for this Expand line-handler process in Step
4: Create a Profile for the Expand-Over-SNA Line-Handler Process.
CPU cpunumber
indicates the processor where this Expand line-handler process will normally
execute.
ALTCPU altcpunumber
indicates the processor where the backup Expand line-handler process will
normally execute.
TYPE (63,0)
is the device type and subtype for this Expand line-handler process. The device
type is always 63 for Expand line-handler processes. The subtype is 0 for singleline Expand-over-SNA line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ASSOCIATEDEV nam_process
specifies the device name of the SNAX/APN line-handler process you want to
associate with this Expand-over-SNA line-handler process.
ASSOCIATESUBDEV subdevice
is a required modifier that specifies the name of the SNAX/APN subdevice to which
the Expand-over-SNA line-handler process will bind. subdevice is a local LU
(with the NAM protocol) defined for the SNAX/APN line-handler process specified
with the ASSOCIATEDEV modifier. Adding LUs is explained in Step 2: Add the LUs
for the SNAX/APN Line on page 11-8.
Expand Configuration and Management Manual—523347-008
11 -13
Configuring Expand-Over-SNA Lines
Considerations
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 through 254) of the system
connected to the other end of the line. If you do not specify NEXTSYS, this
modifier defaults to an invalid value (255) and an operator message occurs during
the initialization of the Expand-over-SNA line-handler process. The path will not be
operational until you alter NEXTSYS to a valid value using either the WAN
subsystem SCF ALTER DEVICE command, or the Expand subsystem SCF ALTER
PATH command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this Expand line-handler process.
Modifier names in the PEXQSNAM profile are listed in Profile Modifiers on
page 11-16.
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXQSNAM profile are
described in Profile Modifiers on page 11-16.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Examples
In the following example, a device named $EXPSL4 is created for a single-line
Expand-over-SNA line-handler process. $EXPSL4 will bind to subdevice #LLUA on the
SNAX/APN line $SNAPA. (See Figure 11-3 on page 11-10 for the commands used to
configure #LLUA and $SNAPA.) The L4TIMEOUT modifier is recommended for
Expand-over-SNA line-handler processes.
-> ADD DEVICE $ZZWAN.#EXPS14, PROFILE SLHSNA, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 32, ASSOCIATEDEV $SNAPA, &
ASSOCIATESUBDEV #LLUA, 14TIMEOUT 3000
Expand Configuration and Management Manual—523347-008
11 -14
Configuring Expand-Over-SNA Lines
Step 6: Start the Expand-Over-SNA Line-Handler
Process
In the next example, the same device is created as part of a multi-CPU path. The
SUPERPATH_ON and L4EXTPACKETS_ON modifiers are required for line-handler
processes that are part of a multi-CPU path. The L4CONGCTRL_ON modifier is
recommended for Expand line-handler processes that are part of a multi-CPU path.
-> ADD DEVICE $ZZWAN.#EXPS14, PROFILE SLHSNA, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,0), &
RSIZE 0, PATHTF 3, NEXTSYS 32, ASSOCIATEDEV $SNAPA, &
ASSOCIATESUBDEV #LLUA, 14TIMEOUT 3000, 14EXTPACKETS_ON, &
14CONGCTRL_ON, SUPERPATH_ON
Step 6: Start the Expand-Over-SNA
Line-Handler Process
To start a single-line Expand-over-SNA line-handler process, use the WAN subsystem
SCF START DEVICE command. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the Expand-over-SNA
line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Step 7: Start the Expand-Over-SNA Line
To start an Expand-over-SNA line, use the Expand subsystem SCF START LINE
command. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-SNA line-handler process.
The successful completion of this command leaves the line in the STARTED state.
Expand Configuration and Management Manual—523347-008
11 -15
Configuring Expand-Over-SNA Lines
Profile Modifiers
Profile Modifiers
This subsection lists the recommended modifiers for Expand-over-SNA line-handler
processes and describes the modifiers provided for configuring special features. It also
describes default values and value ranges for all the modifiers contained in the
PEXQSNAM profile.
Note. A different profile is provided for Expand-over-SNA lines that are part of a multi-line
path; this profile is described in Section 14, Configuring Multi-Line Paths.
Recommended Modifiers
Recommended modifiers are modifiers that should be used to obtain optimum
performance and efficiency. The following modifier is recommended for Expand-overSNA line-handler processes:
L4TIMEOUT n
Default:
Units:
Range:
2000 (20 seconds)
0.01 seconds
500 through 32,767 (5.00 seconds through 5.27.67 minutes)
This modifier specifies the time interval, in one-hundredth of a second increments, that
the Expand-over-SNA line-handler process will wait for a response to an end-to-end
(Layer 4) request before retrying. L4TIMEOUT should be the same for every Expand
line-handler process in the network.
If a message is not acknowledged within the L4TIMEOUT period, an enquiry (ENQ) will
be initiated. Because retransmissions of an SNA network can degrade response time,
cause network link congestion, or result in excessive packet charges, you should set
L4TIMEOUT to a value in excess of the maximum anticipated response time on a
loaded link.
Note. The Expand End-to-End protocol is explained in Path Function of the Expand
Subsystem on page 18-13.
Modifiers for Special Features
The following modifiers are provided in the PEXQSNAM profile to enable you to
configure special features:
•
•
•
•
PATHBLOCKBYTES modifier for the multipacket frame feature
PATHPACKETBYTES modifier for the variable packet size feature
L4CONGCTRL_ON modifier for the congestion control feature
SUPERPATH_ON modifier for the Expand multi-CPU feature
For configuration considerations for these features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of these
features, refer to Section 3, Planning a Network Design.
Expand Configuration and Management Manual—523347-008
11 -16
PEXQSNAM Modifiers
Configuring Expand-Over-SNA Lines
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
PEXQSNAM Modifiers
The disk file $SYSTEM.SYSnn.PEXQSNAM defines modifiers for Expand-over-SNA
line-handler processes.
Table 11-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Table 11-1. PEXQSNAM Modifiers for Expand-over-SNA Lines (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
Any 8-character string
ASSOCIATESUBDEV1
Any 8-character string
COMPRESS_OFF
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
EXTMEMSIZE
2048
0 through 32767
FRAMESIZE
132
64 through 2047
L2RETRIES
10
1 through 255
L4CONGCTRL_OFF
3
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS2
255
0 through 254
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
Expand Configuration and Management Manual—523347-008
11 -17
PEXQSNAM Modifiers
Configuring Expand-Over-SNA Lines
Table 11-1. PEXQSNAM Modifiers for Expand-over-SNA Lines (page 2 of 2)
Modifier
Default Value
Range of Values
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0
0 through 186
RETRYPROBE
20
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
3
SUPERPATH_ON
TIMERINACTIVITY
900
0 through 32767
TIMERPROBE
300
1 through 32767
TIMERRECONNECT
30
0 through 32767
TXWINDOW
4
2 through 7
1. This is a required modifier. It has no default value.
2. This is a required modifier. The default value is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
11 -18
12
Configuring Expand-Over-ServerNet
Lines
The Expand-over-ServerNet line-handler process provides connectivity to a ServerNet
Cluster, which uses this process to provide a high-speed interconnect between
systems over a limited geographic range. The Expand-over-ServerNet line-handler
process uses the NETNAM protocol to access the network access method (NAM)
interface of the ServerNet cluster monitor process, $ZZSCL.
An Expand-over-ServerNet line-handler process can be configured as a single line
only; Expand-over-ServerNet lines cannot participate as a member of a multi-CPU path
(superpath).
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-ServerNet line-handler process to provide Expand-over-ServerNet connectivity.
Figure 12-1 illustrates the process of a local application sending a message to a
remote node.
Figure 12-1. Expand-Over-ServerNet Connectivity Components
Local Node
Processor 1
Application
Processor 2
ServerNet
Cluster Monitor
Process $ZZSCL
Processor 3
Processor ...
Expand/ServerNet
Line-Handler
Message System
MSEB
X Fabric
MSEB
Y Fabric
NonStop
Cluster Switch
NonStop
ClusterSwitch
Remote Node
CDT 047.CDD
Expand Configuration and Management Manual—523347-008
12- 1
Configuring Expand-Over-ServerNet Lines
Expand Manager Process ($ZEXP)
Figure 12-1 depicts a local node consisting of three processors: Processor 1 is running
an application, Procesor 2 is running the ServerNet cluster monitor process ($ZZSCL),
and Processor 3 is running an Expand-over-ServerNet line handler.
The application makes a communications request to the message system. The
message system forwards the request to the Expand-over-ServerNet line handler,
which in turn forwards the request to the ServerNet cluster monitor process ($ZZSCL).
The line handler and $ZZSCL provide the various security permissions to allow the
message system to send the message outside the node. The message system then
forwards the communications request to the MSEBs, through the NonStop Cluster
Switches, and out on the line to the remote node.
The message system at the remote node sends the request to its line handler and
$ZZSCL process for permissions, then forwards it to the remote application.
The components shown for this communications request and other components
necessary for Expand-over-ServerNet lines are described as follows.
Expand Manager Process ($ZEXP)
The Expand subsystem requires that the Expand manager process ($ZEXP) be
running during network operation. For information on running this process, see Task 2:
Start the Expand Manager Process on page 1-2.
External System Area Network Manager (SANMAN)
The External System Area Network Manager (SANMAN) is a new process pair that
runs in every NonStop S-series server connected to a ServerNet cluster. SANMAN
provides the services needed to manage the external ServerNet fabrics and the
system’s access to the fabrics. SANMAN:
•
•
•
Manages the external ServerNet fabrics.
Initializes, monitors, configures, and controls the NonStop Cluster Switches.
Communicates with other processes or objects that require information from or
about the external fabrics.
Message Monitor Process (MSGMON)
MSGMON is a new monitor process that resides in each processor of a server and
executes various functions required by the message system. MSGMON is a helper for
the ServerNet cluster subsystem. MSGMON handles communications between the
ServerNet monitor (SNETMON) and individual processors. MSGMON also logs events
from and generates events on behalf of the IPC subsystem.
Expand Configuration and Management Manual—523347-008
12- 2
Configuring Expand-Over-ServerNet Lines
Modular ServerNet Expansion Boards (MSEBs)
MSGMON is a persistent process. Once it is started, it terminates only in the event of
an internal failure or a termination message from the persistence monitor, $ZPM.
MSGMON is not a process pair.
Note. MSGMON is compatible only with G06.09 and later RVUs of the NonStop Kernel
operating system.
Modular ServerNet Expansion Boards (MSEBs)
MSEBs provide connections for ServerNet cables that link one system enclosure to
another. Unlike SEBs, MSEBs use plug-in cards (PICs) to provide a choice of cable
media for routing ServerNet packets. Two MSEBs are required for each node, one for
the external ServerNet X fabric and the other for the external ServerNet Y fabric.
Network Access Method (NAM)
NAM is a pair of message system dialects that allow use of another process, such as
X.25, SNAX, or FOX, as an Expand communications medium. NAM contains
connection establishment, data transfer, and disconnection phases. For more
information, refer to Expand-to-NAM Interface on page 18-49.
Network Control Process ($NCP)
The network control process ($NCP) initiates and terminates server-to-server
connections and maintains network-related system tables, including routing
information. $NCP must be running at every node in the Expand network before
Expand lines can be started.
Cluster Switch
A cluster switch is a 12-port network switch designed for use in ServerNet networks. In
a ServerNet cluster, a cluster switch provides the physical junction point that enables
multiple nodes to connect to the network. For more information about the cluster
switch, refer to the ServerNet Cluster Manual (for the 6770 cluster switch) or the
ServerNet Cluster 6780 Planning and Installation Guide .
Profile Products
To create a ServerNet cluster that operates with other Expand line types, order
individual profile products for the line types you are using. Profile products include
those in Table 12-1:
Expand Configuration and Management Manual—523347-008
12- 3
ServerNet Cluster Monitor Process ($ZZSCL)
Configuring Expand-Over-ServerNet Lines
Table 12-1. Profile Products Needed for Compatibility With Other Expand Lines
Profile
Line Types Supported
Expand/ServerNet (T0509G06)
Expand-over-ServerNet
Required for everyone
Expand/SWANgroup (T0532G06)
X.25
NETDIRECT
NETSATELLITE
IP
ATM
FOX
Required for new users
Expand/FastPipe (T0533G06)
IP
ATM
FOX
Required for new users
ServerNet Cluster Monitor Process ($ZZSCL)
The ServerNet cluster monitor process, $ZZSCL, monitors and responds to events
relevant to ServerNet cluster operations and is responsible for discovering and
managing the cluster.
The ServerNet cluster monitor process is not limited to a particular processor pair; it
can migrate within a user-specified set. A member of a ServerNet cluster monitor
process pair can go down without its processor going down. If both primary and
backup processes fail, the ServerNet monitor may be absent for a short period, until
the persistence manager starts a new ServerNet cluster monitor process. Since data
traffic does not involve the ServerNet monitor, it could continue during this time.
$ZZSCL must be configured and started before the Expand-over-ServerNet
line-handler processes can be started. For information about configuring $ZZSCL, refer
to the ServerNet Cluster Manual.
ServerNet Cluster Product
ServerNet clusters enable multiple NonStop S-series servers to work together and
appear to client applications as one large processing entity. ServerNet clusters extend
the ServerNet X and Y fabrics outside the system boundary and allow the ServerNet
protocol to be used for intersystem messaging. For more information on the ServerNet
Cluster product, refer to the ServerNet Cluster Manual.
Wide Area Network (WAN) Subsystem
You create an Expand-over-ServerNet line-handler process by adding it as a device to
the WAN subsystem. For each node in a ServerNet cluster, you must create one
Expand-over-ServerNet line-handler process for every other node in the cluster. The
WAN subsystem is preconfigured and started during the system load sequence. For
information about the WAN subsystem, refer to the WAN Subsystem Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
12- 4
Configuring Expand-Over-ServerNet Lines
X and Y Fabrics
X and Y Fabrics
X and Y fabrics are a collection of connected routers and ServerNet links that,
together, provide an interconnection for NonStop S-series servers. Each processor
connects to both fabrics. The X fabric and the Y fabric are not connected to each other;
therefore, a ServerNet packet cannot cross from one fabric to the other and a failure in
one fabric does not affect the other fabric.
Expand Configuration and Management Manual—523347-008
12- 5
Topology Considerations
Configuring Expand-Over-ServerNet Lines
Topology Considerations
A ServerNet cluster must be configured as a logical fully connected mesh—each
server must have one Expand-over-ServerNet line-handler process for each other
node in the ServerNet cluster. A ServerNet cluster can consist of up to 24 nodes.
Figure 12-2 is an example of Expand-over-ServerNet lines in a four-node ServerNet
cluster configuration.
Figure 12-2. Expand-Over-ServerNet Topology
\NODE1
$LINE2
$LINE3
$LINE4
$LINE1
\NODE4
$LINE1
X-Fabric
$LINE2
$LINE4
\NODE2
$X252
$LINE3
Y -Fabric
$LINE3
$LINE4
$LINE1
$LINE2
\NODE3
Key
Configured Single-Line Path
Expand Configuration and Management Manual—523347-008
12- 6
CDT 048.CDD
Summary of Configuration Steps
Configuring Expand-Over-ServerNet Lines
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 12-1 for details), configuring Expand-over-ServerNet
connections involves the following steps:
Step
Tool Used
Step 1: Create a Profile for the Expand-OverServerNet Line-Handler Process
SCF interface to the WAN
subsystem
Step 2: Create a Device for the Expand-OverServerNet Line-Handler Process
SCF interface to the WAN
subsystem
Step 3: Start the Expand-Over-ServerNet Line-Handler
Processes
SCF interface to the WAN
subsystem
Step 4: Start the Expand-Over-ServerNet Lines
SCF interface to the Expand
subsystem.
Note. The SCF command syntax shown in this subsection is the syntax used to configure
Expand-over-ServerNet connections; it is not meant to show the complete syntax of SCF
commands described. Refer to the following manuals for more information:
•
•
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Configuring a ServerNet Node
Refer to the online help for the guided procedure for configuring a ServerNet node for
assistance in preparing a NonStop S-series server to become a node in a ServerNet
cluster. You use the guided procedure to:
•
•
Create a ServerNet cluster for the first time.
Add a node to an already configured ServerNet cluster.
Step 1: Create a Profile for the Expand-OverServerNet Line-Handler Process
You can create a profile for the Expand-over-ServerNet line-handler processes using
the PEXPSSN profile. This profile is provided in the $SYSTEM.SYSnn subvolume. You
can also create a new profile from an existing profile, or you can create your own
profile. For complete information about profiles, refer to the WAN Subsystem
Configuration and Management Manual.
This subsection shows you how to create a profile using PEXPSSN.
Expand Configuration and Management Manual—523347-008
12- 7
Configuring Expand-Over-ServerNet Lines
ADD Profile Command
ADD Profile Command
To create a profile from the PEXPSSN profile template, use the WAN subsystem SCF
ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create devices for the Expand-overServerNet line-handler processes in Step 2: Create a Device for the Expand-OverServerNet Line-Handler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXPSSN is the disk filename of the profile provided for Expand-overServerNet line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXPSSN
profile are listed in Profile Modifiers on page 12-13.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXPSSN profile are described in Profile Modifiers on page 12-13.
Example
In the following example, a profile named PEXPSSN is created for an Expand-overServerNet line-handler process using the PEXPSSN profile. The
AFTERMAXRETRIES_DOWN modifier is set in the profile.
-> ADD PROFILE $ZZWAN.#PEXPSSN, FILE $SYSTEM.SYS01.PEXPSSN &,
AFTERMAXRETRIES_DOWN
Expand Configuration and Management Manual—523347-008
12- 8
Configuring Expand-Over-ServerNet Lines
Step 2: Create a Device for the Expand-OverServerNet Line-Handler Process
Step 2: Create a Device for the Expand-OverServerNet Line-Handler Process
You create an Expand-over-ServerNet line-handler process by adding it as a device to
the WAN subsystem. For each system you add to the ServerNet cluster, you must
configure line-handler processes for all of the other systems in the cluster. On all other
systems in the cluster, you must configure a line-handler process for the system you
are adding.
ADD DEVICE Command
To create an Expand-over-ServerNet line-handler process, use the WAN subsystem
SCF ADD DEVICE command. The command syntax is as follows:
ADD
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,4 )
RSIZE rsize
ASSOCIATEDEV $ZZSCL
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand-over-ServerNet
line-handler process to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for an Expand-over-ServerNet line-handler
process in Step 1: Create a Profile for the Expand-Over-ServerNet Line-Handler
Process.
CPU cpunumber
indicates the processor where this Expand-over-ServerNet line-handler process
will normally execute.
Note. HP recommends that you use the Guided Procedure for Configuring a ServerNet
Node to configure line handlers, to avoid configuring them in processors 0
and 1. For further information, see Considerations.
Expand Configuration and Management Manual—523347-008
12- 9
Configuring Expand-Over-ServerNet Lines
ADD DEVICE Command
ALTCPU altcpunumber
indicates the processor where the backup Expand-over-ServerNet line-handler
process will normally execute.
TYPE (63,4)
is the device type and subtype for Expand-over-ServerNet line-handler processes.
The device type is always 63 for Expand line-handler processes. The subtype is
always 4 for Expand-over-ServerNet line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
ASSOCIATEDEV $ZZSCL
specifies the device name of the ServerNet cluster monitor process, $ZZSCL.
$ZZSCL is the default, but it can be changed.
NEXTSYS sys_number
is a required modifier that specifies the Expand node number (from 0 to 254) of the
system connected to the other end of the line. If you do not specify NEXTSYS, this
modifier defaults to an invalid value (255), and an operator message occurs during
the initialization of the Expand-over-ServerNet line-handler process. The path will
not be operational until you alter NEXTSYS to a valid value using either the WAN
subsystem SCF ALTER DEVICE command, or the Expand subsystem SCF ALTER
PATH command.
modifier_keyword
is the name of a modifier in profile_name. modifier_keyword is added to the
device record for this Expand line-handler process.
Modifier names in the PEXPSSN profile are listed in Profile Modifiers on
page 12-13.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
modifier_value assigns a value to modifier_keyword in the device record
for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXPSSN profile are
described in Profile Modifiers on page 12-13.
Expand Configuration and Management Manual—523347-008
12 -10
Configuring Expand-Over-ServerNet Lines
Considerations
Considerations
•
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Here are recommended configuration guidelines for configuring Expand-overServerNet line handlers. (If you use the Guided Procedure for Configuring a
ServerNet Node, processors 0 and 1 will automatically be avoided.)
a. Configure primary and backup Expand-over-ServerNet line handlers in
processors in different enclosures (except for two-processor systems, which
have only one enclosure).
b. Avoid configuring an Expand-over-ServerNet line handler on processors 0
and 1, if possible. Some other processes can only run in processors 0 and 1,
increasing the impacts of CPU halts. Note that (b) can only be applied in
systems with at least three enclosures. On a four-processor system, the
process pair is to be configured according to (a), meaning that one of the sides
of the pair will run in either processor 0 or 1.
c. Avoid configuring the Expand-over-ServerNet line handler on processors
outside the tetrahedron (processors greater than 9) whenever possible. There
are more ServerNet components (routers and links) along the paths from these
processors to the external fabrics than along paths that originate in processors
within the tetrahedron. Consequently, the probability that these paths may fail
in the presence of hardware faults is higher.
Example
In the following example, a device named #SC001 is created for an Expand-overServerNet line-handler process.
-> ADD DEVICE $ZZWAN.#SC001, PROFILE PEXPSSN, &
IOPOBJECT $SYSTEM.SYSTEM.LHOBJ, CPU 2, ALTCPU 5, TYPE (63,4), &
RSIZE 0, PATHTF 1, ASSOCIATEDEV $ZZSCL, NEXTSYS 102, &
COMPRESS_OFF, PATHBLOCKBYTES 0, PATHPACKETBYTES 4095
Expand Configuration and Management Manual—523347-008
12 -11
Configuring Expand-Over-ServerNet Lines
Step 3: Start the Expand-Over-ServerNet LineHandler Processes
Step 3: Start the Expand-Over-ServerNet LineHandler Processes
To start an Expand-over-ServerNet line-handler process, use the WAN subsystem SCF
START DEVICE command. You must start each Expand-over-ServerNet line-handler
process that you created in Step 2: Create a Device for the Expand-Over-ServerNet
Line-Handler Process. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the Expand-over-ServerNet
line-handler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Example
In the following example, the device named #SC001 is started.
-> START DEVICE $ZZWAN.#SC001
Step 4: Start the Expand-Over-ServerNet Lines
Note. Do not perform this step unless you have already physically connected the NonStop
S-series server to the ServerNet cluster. Connecting a NonStop S-series server to a ServerNet
cluster is described in the ServerNet Cluster Manual.
To start an Expand-over-ServerNet line, use the Expand subsystem SCF command
START LINE. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-ServerNet line-handler process.
Note. Wait about five seconds after starting the device before you start the line.
The successful completion of this command leaves the line in the STARTED state. To
check the status of the line, enter the following SCF command:
STATUS LINE $device_name
Expand Configuration and Management Manual—523347-008
12 -12
Profile Modifiers
Configuring Expand-Over-ServerNet Lines
For the next steps, such as installing a new cluster, migration, or adding a node, see
the ServerNet Cluster Manual or the ServerNet Cluster 6780 Planning and Installation
Guide .
Profile Modifiers
This subsection lists the modifiers provided for configuring special features. It also
describes default values and value ranges for all the modifiers contained in the
PEXPSSN profile.
Modifiers for Special Features
The L4CONGCTRL_ON modifier is provided in the PEXPSSN profile to enable you to
configure the congestion control feature. For configuration considerations for this
feature, refer to Section 18, Subsystem Description. For information about the
advantages and disadvantages of this feature, refer to Section 3, Planning a Network
Design. The L4CONGCTRL_ON modifier is described in detail in Section 17, Expand
Modifiers.
Note. The multipacket frame and variable packet size features are not supported on Expandover-ServerNet connections.
PEXPSSN Modifiers
The disk file $SYSTEM.SYSnn.PEXPSSN defines modifiers for Expand-over-ServerNet
line-handler processes.
Table 12-2 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Table 12-2. PEXPSSN Modifiers for Expand-over-ServerNet Lines (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
$ZZSCL
Any 8-character string
COMPRESS_OFF
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
EXTMEMSIZE
8192
0 through 32767
FRAMESIZE
132
64 through 2047
Expand Configuration and Management Manual—523347-008
12 -13
PEXPSSN Modifiers
Configuring Expand-Over-ServerNet Lines
Table 12-2. PEXPSSN Modifiers for Expand-over-ServerNet Lines (page 2 of 2)
Modifier
Default Value
Range of Values
L2RETRIES
10
1 through 255
L2TIMEOUT
100
20 through 32767
L4CONGCTRL_OFF
3
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS2
255
0 through 254
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0
0 through 186
RETRYPROBE
10
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
OFF
TIMERPROBE
30
30 through 32767
TIMERRECONNECT
60
0 through 32767
TXWINDOW
7
2 through 7
1. This is a required modifier.
2. This is a required modifier. The default value is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
12 -14
13
Configuring Expand-Over-FOX Lines
The Expand-over-FOX line-handler process provides connectivity to an existing FOX
ring. The Expand-over-FOX line-handler process uses the NETNAM protocol to access
the network access method (NAM) interface of the FOX monitor process, $ZZFOX.
An Expand-over-FOX line-handler process can be configured as a single line only;
Expand-over-FOX lines cannot participate as a member of a multi-CPU path
(superpath).
Required Hardware and Software
Several hardware and software components are required in addition to the Expandover-FOX line-handler process to provide Expand-over-FOX connectivity. These
components are illustrated in Figure 13-1 and are explained in the following
subsections.
Figure 13-1. Expand-Over-FOX Connectivity Components
Processor
Expand-over-FOX
Line-Handler
Process
NAM
$ZZFOX
FOX Driver
Y-Fabric
X-Fabric
$ZZFOX.#X
Receive
Transmit
ServerNet/FX
Adapter
Left
Transmit
Receive
Right
Receive
Left
$ZZFOX.#Y
Transmit
ServerNet/FX
Right
Adapter
Transmit
Receive
CDT 040.CDD
Expand Configuration and Management Manual—523347-008
13- 1
Configuring Expand-Over-FOX Lines
FOX Monitor Process ($ZZFOX)
FOX Monitor Process ($ZZFOX)
The FOX monitor process, $ZZFOX, manages the ServerNet/Fiber eXtension
(ServerNet/FX) adapters and is responsible for maintaining configuration information
about the FOX ring. $ZZFOX must be configured and started before the Expand-overFOX line-handler processes can be started. For information about configuring
$ZZFOX, refer to the ServerNet/FX Adapter Configuration and Management Manual.
$ZZFOX.#X and $ZZFOX.#Y
Each ServerNet/FX adapter is identified by a logical interface called an LBU.
$ZZFOX.#X is the name of the LBU that connects to the X-ring and $ZZFOX.#Y is the
name of the LBU that connects to the Y-ring through the ServerNet system area
network (ServerNet SAN). For information about configuring LBUs, refer to the
ServerNet/FX Adapter Configuration and Management Manual.
FOX Driver
The FOX driver is responsible for communicating directly with the ServerNet/FX
adapters. It is provided as part of the NonStop Kernel operating system.
ServerNet/FX Adapters
The ServerNet/FX adapters logically extend the ServerNet fabrics via fiber-optic cables
to other nodes in a FOX-connected network. Two ServerNet/FX adapters are used—
one for the ServerNet X-ring and one for the ServerNet Y-ring.
Once the Expand-over-FOX line-handler processes are started, incoming and outgoing
messages are usually handled directly by the ServerNet fabrics and the ServerNet/FX
adapters; the Expand software is not involved. The Expand-over-FOX line-handler
processes manage security-related messages and forward packets outside the FOX
ring.
The ServerNet/FX adapters and the fiber-optic cabling must be installed before
Expand-over-FOX line-handler processes can be started. The ServerNet/FX adapters
must be installed by a service provider trained by HP. Installation and cabling
information is available in the ServerNet/FX Adapter Installation and Support Guide for
ServerNet/FX adapters and in the ServerNet/FX 2 Adapter Installation and Support
Guide for ServerNet/FX 2 adapters.
Wide Area Network (WAN) Subsystem
You create an Expand-over-FOX line-handler process by adding it as a device to the
WAN subsystem. The WAN subsystem is preconfigured and started during the system
load sequence. For information about the WAN subsystem, refer to the WAN
Subsystem Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
13- 2
Topology Considerations
Configuring Expand-Over-FOX Lines
Topology Considerations
A FOX ring must be configured as a logical fully connected mesh—one Expand-overFOX line-handler process is required for each node, or cluster, in the ring. A FOX ring
can consist of up to 14 clusters. A FOX ring is illustrated in Figure 13-2.
Figure 13-2. Expand-Over-FOX Topology
Cluster 1
$LINE2
$LINE3
X
X
Y
Cluster 4
$LINE4
Y
$LINE1
$LINE1
$LINE2
$LINE4
Cluster 2
$X252
$LINE3
$LINE3
Y
Y
$LINE4
X
X
$LINE1
$LINE2
Cluster 3
Key
$LINE n
Configured path
The line-handler process that connects to cluster
n
CDT 045.CDD
Expand Configuration and Management Manual—523347-008
13- 3
Summary of Configuration Steps
Configuring Expand-Over-FOX Lines
Summary of Configuration Steps
Once all hardware and software requirements have been met (refer to Required
Hardware and Software on page 13-1 for details), configuring Expand-over-FOX
connections involves the following steps:
Step
Tool Used
Step 1: Create a Profile for the Expand-Over-FOX
Line-Handler Process
SCF interface to the WAN
subsystem
Step 2: Create a Device for the Expand-Over-FOX
Line-Handler Process
SCF interface to the WAN
subsystem
Step 3: Start the Expand-Over-FOX Line-Handler
Processes
SCF interface to the WAN
subsystem
Step 4: Start the Expand-Over-FOX Lines
SCF interface to the Expand
subsystem.
Note. The SCF command syntax shown in this subsection is the syntax used to configure
Expand-over-FOX connections; it is not meant to show the complete syntax of SCF commands
described. Refer to the following manuals for more information:
•
•
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Step 1: Create a Profile for the Expand-OverFOX Line-Handler Process
You can create a profile for the Expand-over-FOX line-handler processes using the
PEXQSFX profile. This profile is provided in the $SYSTEM.SYSnn subvolume. You can
also create a new profile from an existing profile, or you can create your own profile.
For complete information about profiles, refer to the WAN Subsystem Configuration
and Management Manual.
This subsection shows you how to create a profile using PEXQSFX.
ADD Profile Command
To create a profile from the PEXQSFX profile template provided, use the WAN
subsystem SCF ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.profile_filename
[, modifier_keyword [ modifier_value ] ] ...
Expand Configuration and Management Manual—523347-008
13- 4
Configuring Expand-Over-FOX Lines
Step 2: Create a Device for the Expand-Over-FOX
Line-Handler Process
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create devices for the Expand-over-FOX
line-handler processes in Step 2: Create a Device for the Expand-Over-FOX LineHandler Process.
FILE $SYSTEM.SYSnn.profile_filename
specifies the name of an existing disk file that will be used to create the new
profile. PEXQSFX is the disk filename of the profile provided for Expand-over-FOX
line-handler processes.
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXQSFX
profile are listed in Profile Modifiers on page 13-8.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXQSFX profile are described in Profile Modifiers on page 13-8.
Example
In the following example, a profile named SLHFX is created for an Expand-over-FOX
line-handler process using the PEXQSFX profile. The AFTERMAXRETRIES_DOWN
modifier is set in the profile.
-> ADD PROFILE $ZZWAN.#SLHFX, FILE $SYSTEM.SYS01.PEXQSFX , &
AFTERMAXRETRIES_DOWN
Step 2: Create a Device for the Expand-OverFOX Line-Handler Process
You create an Expand-over-FOX line-handler process by adding it as a device to the
WAN subsystem. You must create one Expand-over-FOX line-handler process for
each cluster in the FOX ring.
Expand Configuration and Management Manual—523347-008
13- 5
Configuring Expand-Over-FOX Lines
ADD DEVICE Command
ADD DEVICE Command
To create an Expand-over-FOX line-handler process, use the WAN subsystem SCF
ADD DEVICE command. The command syntax is as follows:
ADD
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,3 )
RSIZE rsize
ASSOCIATEDEV $ZZFOX
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#device_name
specifies, via the WAN subsystem, the device name of the Expand-over-FOX linehandler process you want to add.
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object for code for an
Expand line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for an Expand-over-FOX line-handler
process in Step 1: Create a Profile for the Expand-Over-FOX Line-Handler
Process.
CPU cpunumber
indicates the processor where this Expand-over-FOX line-handler process will
normally execute.
ALTCPU altcpunumber
indicates the processor where the backup Expand-over-FOX line-handler process
will normally execute.
TYPE (63,3)
is the device type and subtype for Expand-over-FOX line-handler processes. The
device type is always 63 for Expand line-handler processes. The subtype is always
3 for Expand-over-FOX line-handler processes.
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
Expand Configuration and Management Manual—523347-008
13- 6
Configuring Expand-Over-FOX Lines
Considerations
ASSOCIATEDEV $ZZFOX
specifies the device name of the FOX monitor process, $ZZFOX. $ZZFOX is the
default, but it can be changed.
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 to 254) of the system
connected to the other end of the line. If you do not specify NEXTSYS, this
modifier defaults to an invalid value (255), and an operator message occurs during
the initialization of the Expand-over-FOX line-handler process. The path will not be
operational until you alter NEXTSYS to a valid value using either the WAN
subsystem SCF ALTER DEVICE command, or the Expand subsystem SCF ALTER
PATH command.
modifier_keyword
is the name of a modifier in profile_name. modifier_keyword is added to the
device record for this Expand line-handler process.
Modifier names in the PEXQSFX profile are listed in Profile Modifiers on
page 13-8.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
modifier_value assigns a value to modifier_keyword in the device record
for this Expand line-handler process.
Default values and ranges of values for modifiers in the PEXQSFX profile are
described in Profile Modifiers on page 13-8.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Example
In the following example, a device named $FXLH2 is created for an Expand-over-FOX
line-handler process.
-> ADD DEVICE $ZZWAN.#FXLH2, PROFILE SLHFX, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,3), &
RSIZE 0, PATHTF 3, ASSOCIATEDEV $ZZFOX, NEXTSYS 22
Expand Configuration and Management Manual—523347-008
13- 7
Configuring Expand-Over-FOX Lines
Step 3: Start the Expand-Over-FOX Line-Handler
Processes
Step 3: Start the Expand-Over-FOX LineHandler Processes
To start an Expand-over-FOX line-handler process, use the WAN subsystem SCF
START DEVICE command. You must start each Expand-over-FOX line-handler
process that you created in Step 2: Create a Device for the Expand-Over-FOX LineHandler Process. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.device_name
specifies, via the WAN subsystem, the device name of the Expand-over-FOX linehandler process.
This command creates the specified Expand line-handler process and allocates a
logical device (LDEV) number.
Step 4: Start the Expand-Over-FOX Lines
Note. Do not perform this step unless you have already physically connected the NonStop
S-series server to the FOX ring. Connecting a NonStop S-series server to a FOX ring is
described in the ServerNet/FX Adapter Installation and Support Guide for ServerNet/FX
adapters and in the ServerNet/FX 2 Adapter Installation and Support Guide for ServerNet/FX 2
adapters.
To start an Expand-over-FOX line, use the Expand subsystem SCF command START
LINE. The command syntax is as follows:
START LINE $device_name
device_name
is the device name of the Expand-over-FOX line-handler process.
The successful completion of this command leaves the line in the STARTED state.
Profile Modifiers
This subsection lists the modifiers provided for configuring special features. It also
describes default values and value ranges for all the modifiers contained in the
PEXQSFX profile.
Expand Configuration and Management Manual—523347-008
13- 8
Modifiers for Special Features
Configuring Expand-Over-FOX Lines
Modifiers for Special Features
The L4CONGCTRL_ON modifier is provided in the PEXQSFX profile to enable you to
configure the congestion control feature. For configuration considerations for this
feature, refer to Section 18, Subsystem Description. For information about the
advantages and disadvantages of this feature, refer to Section 3, Planning a Network
Design. The L4CONGCTRL_ON modifier is described in detail in Section 17, Expand
Modifiers.
PEXQSFX Modifiers
The disk file $SYSTEM.SYSnn.PEXQSFX defines modifiers for Expand-over-FOX linehandler processes.
Table 13-1 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Table 13-1. PEXQSFX Modifiers for Expand-over-FOX Lines (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
$ZZFOX
Any 8-character string
COMPRESS_OFF
COMPRESS_ON
3
CONNECTTYPE_ACTIVEANDPASSIVE
3
CONNECTTYPE_PASSIVE
EXTMEMSIZE
8192
0 through 32767
FRAMESIZE
132
64 through 2047
L2RETRIES
10
1 through 255
L2TIMEOUT
100
20 through 32767
L4CONGCTRL_OFF
3
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
LINEPRIORITY
1
1 through 9
Expand Configuration and Management Manual—523347-008
13- 9
PEXQSFX Modifiers
Configuring Expand-Over-FOX Lines
Table 13-1. PEXQSFX Modifiers for Expand-over-FOX Lines (page 2 of 2)
Modifier
Default Value
Range of Values
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
NEXTSYS2
255
0 through 254
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0
0 through 186
RETRYPROBE
10
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
SUPERPATH_OFF
OFF
TIMERPROBE
30
30 through 32767
TIMERRECONNECT
60
0 through 32767
TXWINDOW
7
2 through 7
1. This is a required modifier.
2. This is a required modifier. The default value is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
13 -10
14
Configuring Multi-Line Paths
The Expand multi-line path feature enables you to configure as many as eight lines
between the two adjacent nodes. The Expand subsystem can simultaneously transmit
data over all the lines in a multi-line path, thus increasing overall bandwidth, and will
automatically retransmit data over remaining lines if one or more lines fail. A multi-line
path can be part of a multi-CPU path.
This section explains how to configure the Expand multi-line path feature.
Note. For information about the benefits and disadvantages of configuring multi-line paths,
refer to Section 3, Planning a Network Design.
Configuration Overview
A multi-line path requires a logical device to manage the path function (called a pathlogical device) and a separate logical device for each line in the path (called a linelogical device). Each line-logical device is associated with a path-logical device. The
path-logical device and the line-logical devices with which it is associated are regarded
as a single Expand line-handler process by the Expand subsystem.
Note. The path and line functions of an Expand line-handler process are described in detail in
Expand Subsystem and the OSI Reference Model on page 18-9.
Figure 14-1 shows the logical devices required for a multi-line path that consists of four
lines.
Figure 14-1. Logical Devices for a Multi-Line Path
Path Logical Device
Line Logical Devices
$LINE1
$PATH
$LINE2
$LINE3
$LINE4
CDT 039.CDD
Expand Configuration and Management Manual—523347-008
14- 1
Configuration Considerations
Configuring Multi-Line Paths
Configuration Considerations
Consider the following when configuring a multi-line path:
•
•
•
•
•
•
You can configure a maximum of eight lines in a multi-line path.
The lines in a multi-line path can be all the same type (for example, all dedicated),
or they can be any combination of dedicated lines, X.25 connections, and SNAX
connections. You cannot mix satellite-connect, Expand-over-ATM, and Expandover-IP lines with other line types.
Expand-over-ServerNet and Expand-over-FOX connections cannot participate as a
member of a multi-CPU path (superpath).
A path-logical device and the line-logical devices with which it is associated must
be configured in the same processor pair.
A multi-CPU path that consists of Expand-over-IP lines can achieve better
throughput than a multi-line path that consists of Expand-over-IP lines. For more
information about multi-CPU paths and Expand-over-IP, refer to When to Use a
Multi-CPU Path on page 3-10.
For multi-line paths, the configured line speed, the packet size, and the DELAY
parameter (if applicable) are used to calculate when an outgoing packet will arrive
at the other side. This calculation is then used to select the best line for data
transmission. The line speed is configured using the same parameters used to set
the time factor for the line, but with different priorities. For this purpose SPEEDK
overrides SPEED, which overrides LINETF, then RSIZE. Regardless of how the
time factor is calculated, SPEED will be based on the resulting time factor using
the formula:
SPEED = 224000 / (time_factor_of_line)
•
When PathTF is set for a multi-line path, the line state and number of lines in the
path are ignored and the PathTF setting is a constant value assigned to the time
factor for the path. See PATHTF n on page 17-20 for more information about this
recommended setting.
Summary of Configuration Steps
Configuring and starting a multi-line path involves the following steps:
Task
Tool Used
Step 1: Create a Profile for the Path-Logical Device
SCF interface to the WAN subsystem
Step 2: Create a Profile for Each Line Type
SCF interface to the WAN subsystem
Step 3: Create a Path-Logical Device
SCF interface to the WAN subsystem
Expand Configuration and Management Manual—523347-008
14- 2
Configuring Multi-Line Paths
Step 1: Create a Profile for the Path-Logical Device
Task
Tool Used
Step 4: Create the Line-Logical Devices
SCF interface to the WAN subsystem
Step 5: Start the Path-Logical Device
SCF interface to the WAN subsystem
Step 6: Start the Lines
SCF interface to the Expand
subsystem
Note. The SCF command syntax shown in this section is the syntax used to configure multiline paths; it is not meant to show the complete syntax of the SCF commands described. Refer
to the following manuals for more information:
•
•
WAN Subsystem Configuration and Management Manual for WAN subsystem SCF
commands
Section 15, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF
commands
Step 1: Create a Profile for the Path-Logical
Device
You can create a profile for a path-logical device using the PEXPPATH profile. This
profile is provided in the $SYSTEM.SYSnn subvolume. You can also create a profile
from an existing profile, or you can create your own profile. For complete information
about profiles, refer to the WAN Subsystem Configuration and Management Manual.
This subsection shows you how to create a profile using PEXPPATH.
ADD PROFILE Command
To create a profile from the PEXPPATH profile template, use the WAN subsystem SCF
ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.PEXPPATH
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create the device for the path in Step 3:
Create a Path-Logical Device.
FILE $SYSTEM.SYSnn.PEXPPATH
specifies the name of an existing disk file that will be used to create the new
profile. PEXPPATH is the disk filename of the profile provided for path-logical
devices.
Expand Configuration and Management Manual—523347-008
14- 3
Configuring Multi-Line Paths
Step 2: Create a Profile for Each Line Type
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the PEXPPATH
profile are listed in PEXPPATH Modifiers on page 14-15.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the
PEXPPATH profile are described in PEXPPATH Modifiers on page 14-15.
Step 2: Create a Profile for Each Line Type
You must create a profile for each type of line that will be in the multi-line path. For
example, if the multi-line path will consist of one direct-connect line and one Expandover-SNA line, you must create two profiles, one for each line type. If the multi-line
path will consist of two direct-connect lines, you need only create one profile because
both lines can share the same profile.
You can create a profile for a line-logical device using one of the line-logical device
profiles. These profiles are installed in the $SYSTEM.SYSnn subvolume. You can also
create a profile from an existing profile, or you can create your own profile. For
complete information about profiles, refer to the WAN Subsystem Configuration and
Management Manual.
This subsection shows you how to create a profile using one of the line-logical device
profiles.
ADD PROFILE Command
To create a profile from one of the line-logical device profile templates, use the WAN
subsystem SCF ADD PROFILE command. The command syntax is as follows:
ADD PROFILE $ZZWAN.#profile_name
, FILE $SYSTEM.SYSnn.diskfile_name
[, modifier_keyword [ modifier_value ] ] ...
$ZZWAN.profile_name
specifies, via the WAN subsystem, a user-defined name of up to eight
alphanumeric characters that will be used to identify the new profile. You will
reference this profile_name when you create the device for the line in Step 4:
Create the Line-Logical Devices.
FILE $SYSTEM.SYSnn.diskfile_name
specifies the name of an existing disk file that will be used to create the new
profile. Table 14-1 lists the disk filenames that are provided for line-logical devices.
These disk files are installed in $SYSTEM.SYSnn.
Expand Configuration and Management Manual—523347-008
14- 4
Step 3: Create a Path-Logical Device
Configuring Multi-Line Paths
Table 14-1. Profiles for Line-Logical Devices
Disk Filename
Type of Line-Logical Device
PEXQMSWN
Direct-connect
PEXQMSAT
Satellite-connect
PEXQMNAM
Expand-over-NAM
PEXQMIP
Expand-over-IP
PEXQMATM
Expand-over-ATM
modifier_keyword
is the name of a modifier in profile_name. Modifier names in the line-logical
device profiles are listed in Line-Logical Device Modifiers on page 14-16.
modifier_value
is the value you want to assign to the modifier specified by modifier_keyword.
Specifying a modifier_value assigns a new value to modifier_keyword in
profile_name. Default values and ranges of values for modifiers in the linelogical device profiles are described in Line-Logical Device Modifiers on
page 14-16.
Step 3: Create a Path-Logical Device
You create a path-logical device by adding a device to the WAN subsystem.
ADD DEVICE Command
To create a path-logical device, use the WAN subsystem SCF ADD DEVICE
command. The command syntax is as follows:
ADD
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#path_name
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
PROFILE profile_name
CPU cpunumber
ALTCPU altcpunumber
TYPE (63,1)
RSIZE 0
NEXTSYS sys_number
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.#path_name
specifies, via the WAN subsystem, the name of the path-logical device you want to
add.
Expand Configuration and Management Manual—523347-008
14- 5
Configuring Multi-Line Paths
ADD DEVICE Command
IOPOBJECT $SYSTEM.SYSnn.LHOBJ
is the name of the object file containing the executable object code for an Expand
line-handler process. This value must be $SYSTEM.SYSnn.LHOBJ.
PROFILE profile_name
is the name of the profile you created for the path in Step 1: Create a Profile for the
Path-Logical Device.
CPU cpunumber
is the processor number where the path-logical device will normally execute.
ALTCPU altcpunumber
is the processor number where the backup path-logical device will normally
execute.
TYPE (63,1)
is the device type and subtype for the path-logical device. The device type is
always 63 for Expand line-handler processes. The subtype is always 1 for pathlogical devices.
RSIZE 0
The RSIZE value must be set to 0.
NEXTSYS sys_number
is a required modifier that specifies the number (from 0 through 254) of the system
connected to the other end of the path. If you do not specify NEXTSYS, this
modifier defaults to an invalid value (255) and an operator message occurs during
the initialization of the path-logical device. The path will not be operational until you
alter NEXTSYS to a valid value using either the WAN subsystem SCF ALTER
DEVICE command or the Expand subsystem SCF ALTER PATH command.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this path-logical device.
Modifier names in the PEXPPATH profile are listed in PEXPPATH Modifiers on
page 14-15.
Note. If the multi-line path will be part of a multi-CPU path, you must specify the
SUPERPATH_ON and L4EXTPACKETS_ON modifiers when you configure the path-logical
device. The L4CONGCTRL_ON modifier is recommended for multi-CPU paths.
Expand Configuration and Management Manual—523347-008
14- 6
Configuring Multi-Line Paths
Considerations
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword. modifier_value assigns a value to modifier_keyword
in the device record for this path-logical device.
Default values and ranges of values for modifiers in PEXPPATH are described in
PEXPPATH Modifiers on page 14-15.
Considerations
•
•
Not all modifiers have associated values (for example, L4EXTPACKETS_ON).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Step 4: Create the Line-Logical Devices
You must create a line-logical device for each line in the multi-line path. You create a
line-logical device by adding it as a device to the WAN subsystem. All line-logical
devices must be configured in the same processor pair as the path-logical device with
which they are associated.
ADD DEVICE Command
To create a line-logical device, use the WAN subsystem SCF ADD DEVICE command.
The command syntax is as follows:
ADD
,
,
,
,
,
,
,
,
[,
DEVICE $ZZWAN.#device_name
IOPOBJECT iop_object_filename
PROFILE profile_name
CPU cpunumber
ALTCPU altcpununumber
TYPE ( 63, devsubtype )
RSIZE rsize
MULTI $path_name
required_modifier modifier_value ...
modifier_keyword [ modifier_value ] ] ...
$ZZWAN.device_name
specifies, via the WAN subsystem, the name of the line-logical device to add.
IOPOBJECT iop_object_filename
is the name of the object file containing the executable object for code for a linelogical device. This value must be the same as that of the associated path device.
Expand Configuration and Management Manual—523347-008
14- 7
ADD DEVICE Command
Configuring Multi-Line Paths
PROFILE profile_name
is the name of the profile you created for this type of line in Step 2: Create a Profile
for Each Line Type.
CPU cpunumber
is the processor number where the line-logical device will normally execute.
ALTCPU altcpunumber
is the processor number where the backup line-logical device will normally
execute.
TYPE devsubtype
is the device subtype for this line-logical device. The device subtypes for linelogical devices are listed in Table 14-2.
Table 14-2. Device Subtypes for Line-Logical Devices
Type of Line-Logical Device
Subtype
Profile Disk Filename
Direct-connect
6
PEXQMSWN
Satellite-connect
6
PEXQMSAT
Expand-over-NAM
2
PEXQMNAM
Expand-over-IP
2
PEXQMIP
Expand-over-ATM
2
PEXQMATM
RSIZE rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
MULTI path_name
is the name of the path-logical device you want to associate with this line. (You
created a path-logical device in Step 3: Create a Path-Logical Device.)
required_modifier modifier_value
is the name of a required modifier and its associated value in profile_name.
required_modifier and modifier_value are added to the device record for
this line-logical device.
Expand Configuration and Management Manual—523347-008
14- 8
Configuring Multi-Line Paths
ADD DEVICE Command
Required Modifiers for Direct-Connect and Satellite-Connect
Lines
ADAPTER concname
is the ServerNet wide area network (SWAN) concentrator to be used by this line.
Selecting a SWAN concentrator is explained in Step 1: Find an Available WAN Line
on page 7-6. For information about adding SWAN concentrators, refer to the WAN
Subsystem Configuration and Management Manual.
CLIP clipnum
is the communications line interface processor (CLIP) number on the SWAN
concentrator specified by concname that contains an available WAN line. Refer to
Step 1: Find an Available WAN Line on page 7-6 for information about identifying
CLIP numbers. Valid values are 1, 2, and 3.
LINE linenum
is the number of an available WAN line on the CLIP specified by clipnum. Refer
to Step 1: Find an Available WAN Line on page 7-6 for information about identifying
line numbers. Valid values are 0 or 1.
PATH { A | B }
is the path (A or B) on the CLIP specified by clipnum that you prefer. The path
must be configured. For information about adding Ethernet paths, refer to the WAN
Subsystem Configuration and Management Manual.
modifier_keyword
is the name of an optional modifier in profile_name. modifier_keyword is
added to the device record for this line-logical device.
Modifier names in the line-logical device profiles are listed in Line-Logical Device
Modifiers on page 14-16.
modifier_value
is the value you want to assign to the optional modifier specified by
modifier_keyword modifier_value assigns a value to modifier_keyword
in the device record for this line-logical device.
Default values and ranges of values for modifiers in the line-logical device profiles
are described in Line-Logical Device Modifiers on page 14-16.
Expand Configuration and Management Manual—523347-008
14- 9
Configuring Multi-Line Paths
ADD DEVICE Command
Required Modifiers for Expand-Over-IP Lines
SRCIPADDR src_ipaddr
is a required modifier that specifies the IP address associated with the NonStop
TCP/IP process used by this Expand-over-IP line-handler process. Determining IP
addresses is described in Step 1 (A): Select a Process and SUBNET for NonStop
TCP/IP Use on page 8-9. The address must be specified by number (for example,
130.252.12.3). It is not validated and need not be accessible. The default is
0.0.0.1.
SRCIPPORT src_ipport
is a required modifier that specifies the User Datagram Protocol (UDP) port
number used by this Expand-over-IP line-handler process. Determining port
numbers is described in Step 2 (A): Identify an Available UDP Port Number on
page 8-16. Valid values are in the range 0 through 65534. The default is 1024. HP
recommends that you do not use a well-known port in the range from 0 through
1023.
DESTIPADDR dest_ipaddr
is a required modifier that specifies the IP address used by the remote
(destination) Expand-over-IP line. It is the IP address specified in the remote line’s
SRCIPADDR modifier. Determining IP addresses is described in Step 1 (A): Select
a Process and SUBNET for NonStop TCP/IP Use on page 8-9. The address must
be specified by number (for example, 130.252.12.3). It is not validated and need
not be accessible. The default is 0.0.0.1.
DESTIPPORT dest_ipport
is a required modifier that specifies the port number used by the remote
(destination) Expand-over-IP line. It is the port number specified in the remote linehandler process’ SRCIPPORT modifier. Determining port numbers is described in
Step 2 (A): Identify an Available UDP Port Number on page 8-16. Valid values are
in the range 0 through 65534. The default is 1024. HP recommends that you do
not use a well-known port in the range from 0 through 1023.
V6DESTIPADDR v6dest_ipport
is a required modifier that specifies the IP address used by the remote NonStop
TCP/IPv6 (destination) Expand-over-IP line. It is the IP address specified in the
remote line’s V6SRCIPADDR modifier. Determining IP addresses is described in
Step 1 (C): Select a Process and SUBNET for NonStop TCP/IPv6 Use on
page 8-13. The address must be specified by number (for example,
1611:1071:F881:1167:1611:A071:1881:B167). It is not validated and need not be
accessible. The default is 0000:0000:0000:0000:0000:0000:0000:0000.
Expand Configuration and Management Manual—523347-008
14 -10
Configuring Multi-Line Paths
ADD DEVICE Command
V6SRCIPADDR v6src_ipaddr
is a required modifier that specifies the IP address associated with the NonStop
TCP/IPv6 process used by this Expand-over-IP line-handler process. Determining
IP addresses is described in Step 1 (C): Select a Process and SUBNET for
NonStop TCP/IPv6 Use on page 8-13. The address must be specified by number
(for example, 31CA:B145:5489:1034:1784:B245:4029:1257). It is not validated and
need not be accessible. The default is
0000:0000:0000:0000:0000:0000:0000:0000.
Required Modifiers for Expand-Over-ATM Lines
ASSOCIATESUBDEV #IP
identifies the ATM service access point (SAP). The only currently supported ATM
SAP is #IP.
CALLTYPE_ATMSAP
indicates that the ATMSAP connection through the SLSA subsystem will be used.
Either CALLTYPE_ATMSAP, CALLTYPE_PVC, or CALLTYPE_SVC is required.
CALLTYPE_PVC
indicates that a permanent virtual circuit (PVC) connection will be used. Either
CALLTYPE_ATMSAP, CALLTYPE_PVC, or CALLTYPE_SVC is required.
CALLTYPE_SVC
indicates that a switched virtual circuit (SVC) connection will be used. Either
CALLTYPE_ATMSAP, CALLTYPE_PVC, or CALLTYPE_SVC is required.
LIFNAME lif_name
is the name of the ATMSAP connection that will be used. For example, LIF01.
Identifying LIF names is described in Configuring an Expand Line-Handler Process
That Uses ATMSAP on page 9-9.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use ATMSAP connections.
PVCNAME pvc_name
is the name of the PVC connection that will be used. For example, PVC01.
Identifying PVC names is described in Configuring an Expand Line-Handler
Process That Uses a PVC on page 9-6.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use PVC connections.
Expand Configuration and Management Manual—523347-008
14 -11
Configuring Multi-Line Paths
Considerations
ATMSEL selector_byte
is a hexadecimal selector byte for the ATM line used by this Expand-over-ATM linehandler process. Obtaining selector bytes is described in Obtaining Selector Bytes
for the Local and Remote ATM Lines on page 9-6.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use SVC connections.
DESTATMADDR (ISONSAP:%Hatm_address)
is the 20-byte ATM address configured for the ATM line used by the Expand-overATM line-handler process at the remote system. The address must be preceded by
the characters ISONSAP:%H and must be enclosed in parentheses. For example:
(ISONSAP:%H47000580FFE1000000F21A29EB0000000001B300)
Identifying ATM addresses is described in Identifying the ATM Address Configured
for the Remote ATM Line on page 9-7.
This modifier is only applicable to Expand-over-ATM line-handler processes that
use SVC connections.
Required Modifiers for Expand-Over-NAM Lines
ASSOCIATEDEV $nam_process
is a required modifier that specifies the device name of the X25AM line-handler
process or SNAX/APN line-handler process you want to associate with this
Expand-over-X.25 or Expand-over-SNA line.
ASSOCIATESUBDEV #subdevice
is a required modifier that specifies the name of an X25AM subdevice to which the
Expand-over-X.25 line-handler process will bind or the subdevice name of the
SNAX/APN logical unit (LU) used by the Expand-over-SNAX line-handler process.
Configuring X25AM subdevices is explained in Step 1: Add a NAM Subdevice to
the X25AM Line on page 10-7. Configuring a SNAX/APN LUs is explained in Step
2: Add the LUs for the SNAX/APN Line on page 11-8.
Considerations
•
•
Not all modifiers have associated values (for example, CLOCKMODE_DCE).
The modifier_keyword and modifier_value parameters do not add the
specified modifier, or a modifier and its associated value, to the profile used by the
device. Use the ADD PROFILE command to add a modifier, or a modifier and its
associated value, to a profile.
Expand Configuration and Management Manual—523347-008
14 -12
Configuring Multi-Line Paths
Step 5: Start the Path-Logical Device
Step 5: Start the Path-Logical Device
To start the path-logical device, use the WAN subsystem SCF START DEVICE
command. When you use this command on the path-logical device, the line-logical
devices associated with the path are also started. The command syntax is as follows:
START DEVICE $ZZWAN.#device_name
$ZZWAN.#device_name
specifies, via the WAN subsystem, the path-logical device name or a line-logical
device name.
This command creates a process for the specified path-logical device or line-logical
device and allocates one logical device (LDEV) number for the logical-path device and
one LDEV number for each logical-line device.
Step 6: Start the Lines
To start all the lines in the multi-line path, use the Expand subsystem SCF START
PATH command. The command syntax is as follows:
START PATH $device_name
device_name
is the path-logical device name.
The successful completion of this command leaves the path and all the lines in the
path in the STARTED state.
Starting Specific Lines
To start specific lines in a multi-line path, use the Expand subsystem SCF START LINE
command. The command syntax is as follows:
START LINE $device_name
device_name
is the line-logical device name.
The successful completion of this command leaves the specified line and its
associated path in the STARTED state. Other lines in the multi-line path are not
started.
Expand Configuration and Management Manual—523347-008
14 -13
Configuration Example
Configuring Multi-Line Paths
Configuration Example
The following example shows a multi-line path with one direct-connect line and one
Expand-over-SNA line. Figure 14-2 illustrates the configuration of this example.
Figure 14-2. Multi-Line Configuration Example
MULTI
$LINE1
SWAN003A
$PATH
$SNA1
$LINE2
MULTI
SWANxxxxx
ASSOCIATEDEV
CDT 046.CDD
Note. The SWAN concentrator used by the SNAX/APN process $SNA1 is shown as a
transparent box because it is not configured in the following command example.
The following command examples show the WAN subsystem SCF commands used to
configure the multi-line path shown in Figure 14-2.
•
The following SCF ADD PROFILE command creates a profile for a path-logical
device named EXPPATH using the PEXPPATH profile:
-> ADD PROFILE $ZZWAN.#EXPPATH, FILE $SYSTEM.SYS01.PEXPPATH
•
The following SCF ADD PROFILE command creates a profile named MLHTER
that will be used by the direct-connect line in the multi-line path. MLHDIR is
created using the PEXQMSWN profile.
-> ADD PROFILE $ZZWAN.#MLHDIR, FILE $SYSTEM.SYS01.PEXQMSWN
•
The following SCF ADD PROFILE command creates a profile named MLHSNA
that will be used by the Expand-over-SNA line in the multi-line path. MLHSNA is
created using the PEXQMNAM profile.
-> ADD PROFILE $ZZWAN.#MLHSNA, FILE $SYSTEM.SYS01.PEXQMNAM
•
The following SCF ADD DEVICE command creates a path-logical device named
$PATH. Note that $PATH uses the EXPPATH profile created above.
-> ADD DEVICE $ZZWAN.#PATH, PROFILE EXPPATH, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,1), &
RSIZE 0, PATHTF 1, NEXTSYS 21, l4TIMEOUT 3000
Expand Configuration and Management Manual—523347-008
14 -14
Configuring Multi-Line Paths
•
Path-Logical Device Modifiers
The following SCF ADD DEVICE command creates a line-logical device named
$LINE1 for the direct-connect line. Note that the MLHDIR profile created above is
used.
-> ADD DEVICE $ZZWAN.#LINE1, PROFILE MLHDIR, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 0, ALTCPU 1, TYPE (63,5), &
RSIZE 0, LINETF 2, MULTI $PATH, CLIP 2, LINE 0, &
ADAPTER SWAN003A, PATH A
•
The following SCF ADD DEVICE command creates a line-logical device named
$LINE2 for the Expand-over-SNA line. Note that the MLHSNA profile created
above is used.
-> ADD DEVICE $ZZWAN.#LINE2, PROFILE MLHSNA, IOPOBJECT &
$SYSTEM.SYSTEM.LHOBJ, CPU 1, ALTCPU 2, TYPE (63,2), &
RSIZE 0, LINETF 3, MULTI $PATH, ASSOCIATEDEV $SNA1, &
ASSOCIATESUBDEV #SNAM
Path-Logical Device Modifiers
This subsection describes the modifiers provided to configure special features and the
default values and ranges for the modifiers contained in the PEXPPATH profile.
Modifiers for Special Features
The following modifiers are provided in the PEXPPATH profile to enable you to
configure special features:
•
•
•
•
PATHBLOCKBYTES for the multipacket frame feature
PATHPACKETBYTES for the variable packet size feature
L4CONGCTRL_ON for the congestion control feature
SUPERPATH_ON for the Expand multi-CPU feature
For configuration considerations for these features, refer to Section 18, Subsystem
Description. For information about the advantages and disadvantages of these
features, refer to Section 3, Planning a Network Design.
The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, and
SUPERPATH_ON modifiers are described in detail in Section 17, Expand Modifiers.
PEXPPATH Modifiers
The disk file $SYSTEM.SYSnn.PEXPPATH defines modifiers for path-logical devices.
Table 14-3 lists the default value and range of values for each modifier in this profile, if
applicable. For modifiers that are mutually exclusive, a check mark (3) is shown in the
“Default Value” column to indicate which modifier is present in the profile. For a
complete description of the modifiers listed in this table, refer to Section 17, Expand
Modifiers.
Expand Configuration and Management Manual—523347-008
14 -15
Line-Logical Device Modifiers
Configuring Multi-Line Paths
Table 14-3. PEXPPATH Modifiers
Modifier
Default Value
Range of Values
COMPRESS_OFF
COMPRESS_ON
3
L4CONGCTRL_OFF
3
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
3
L4RETRIES
3
3 through 255
L4SENDWINDOW
254
187 through 254
L4TIMEOUT
2000
50 through 32767
NEXTSYS1
255
0 through 254
OSSPACE
32767
3072 through 32767
OSTIMEOUT
300
10 through 32767
PATHBLOCKBYTES
0
0 through 4095
PATHPACKETBYTES
1024
0 through 4095
PATHTF
0 (not set)
0 through 186
SUPERPATH_OFF
3
SUPERPATH_ON
1. This is a required modifier. The default value is invalid and must be changed.
Line-Logical Device Modifiers
This subsection lists the modifiers for line-logical devices and describes the default
value and range of values for each modifier in the PEXQMSWN, PEXQMNAM,
PEXQMSAT, PEXQMATM, and PEXQMIP profiles. For a complete description of the
modifiers listed in this subsection, refer to Section 17, Expand Modifiers.
Note. There are no required modifiers for direct-connect and satellite-connect lines in a multiline path.
X25AM Process Modifiers
You might need to set the following X25AM modifier when configuring an X25AM
process to be used by an Expand-over-X.25 line. This modifier is described in detail in
the X25AM Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
14 -16
PEXQMSWN and PEXQMSAT Modifiers
Configuring Multi-Line Paths
L3WINDOW n
Default:
Units:
Range:
2
Packets
1 through 15 (L3MOD128), 1 through 7 (L3MOD8)
This modifier specifies the number of packets that can be outstanding without an
acknowledgment from the network. You should set L3WINDOW to the largest possible
value.
Note. Some X.25 networks limit the size of L3WINDOW. Consult your vendor for more
information.
PEXQMSWN and PEXQMSAT Modifiers
The disk file $SYSTEM.SYSnn.PEXQMSWN defines modifiers for direct-connect lines in
multi-line paths. The disk file $SYSTEM.SYSnn.PEXQMSAT defines modifiers for
satellite-connect lines in multi-line paths. Table 14-4 lists the default value and range of
values for each modifier in this profile, if applicable. For modifiers that are mutually
exclusive, a check mark (3) is shown in the “Default Value” column to indicate which
modifier is present in the profile.
Table 14-4. PEXQMSWN and PEXQMSAT Modifiers (page 1 of 2)
Modifier
Default Value
CLOCKMODE_DCE
3
Range of Values
CLOCKMODE_DTE
CLOCKSPEED_600
CLOCKSPEED_1200
CLOCKSPEED_2400
CLOCKSPEED_4800
CLOCKSPEED_9600
CLOCKSPEED_19200
3
CLOCKSPEED_38400
CLOCKSPEED_56000
CLOCKSPEED_115200
DELAY
10
0 through 511
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
FLAGFILL_OFF
FLAGFILL_ON
3
FRAMESIZE
132
INTERFACE_RS232
3
64 through 2047
Expand Configuration and Management Manual—523347-008
14 -17
PEXQMNAM Modifiers
Configuring Multi-Line Paths
Table 14-4. PEXQMSWN and PEXQMSAT Modifiers (page 2 of 2)
Modifier
Default Value
Range of Values
INTERFACE_RS422
L2DISCARDONRESET_OFF
L2DISCARDONRESET_ON
3
L2RETRIES
10
1 through 255
L2TIMEOUT
100
20 through 32767
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
PROGRAM
$SYSTEM.CSSnn.
C1097P00 (directconnect)
$SYSTEM.CSSnn.
C1098P00 (satelliteconnect)
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60 seconds
0 to 77600 (12hrs)
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
TXWINDOW
7 (direct-connect)
18 (satellite-connect)
2 through 61
PEXQMNAM Modifiers
The disk file $SYSTEM.SYSnn.PEXQMNAM defines modifiers for Expand-over-NAM
lines in multi-line paths. Table 14-5 lists the default value and range of values for each
modifier in this profile, if applicable. For modifiers that are mutually exclusive, a check
mark (3) is shown in the “Default Value” column to indicate which modifier is present in
the profile.
Table 14-5. PEXQMNAM Modifiers (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
Any 8-character string
ASSOCIATESUBDEV1
Any 8-character string
Expand Configuration and Management Manual—523347-008
14 -18
PEXQMIP Modifiers
Configuring Multi-Line Paths
Table 14-5. PEXQMNAM Modifiers (page 2 of 2)
Modifier
Default Value
CONNECTTYPE_ACTIVEANDPASSIVE
3
Range of Values
CONNECTTYPE_PASSIVE
FRAMESIZE
132
64 through 2047
L2RETRIES
10
1 through 255
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
RETRYPROBE
20
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
TXWINDOW
7
2 through 61
1. This is required modifier. It has no default value.
PEXQMIP Modifiers
The disk file $SYSTEM.SYSnn.PEXQMIP defines modifiers for Expand-over-IP lines in
multi-line paths. Table 14-6 lists the default value and range of values for each modifier
in this profile, if applicable. For modifiers that are mutually exclusive, a check mark (3)
is shown in the “Default Value” column to indicate which modifier is present in the
profile.
Table 14-6. PEXQMIP Modifiers (page 1 of 2)
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
AFTERMAXRETRIES_PASSIVE
3
ASSOCIATEDEV1
None
CONNECTTYPE_ACTIVEANDPASSIVE
3
Any 8-character string
CONNECTTYPE_PASSIVE
DESTIPADDR 2
0.0.0.1
Any 36-character string
DESTIPPORT 1
1024
0 through 65534
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
EXTMEMSIZE
2048
0 through 32767
Expand Configuration and Management Manual—523347-008
14 -19
PEXQMIP Modifiers
Configuring Multi-Line Paths
Table 14-6. PEXQMIP Modifiers (page 2 of 2)
Modifier
Default Value
Range of Values
FRAMESIZE
132
64 through 2047
IPVER_IPV4
3
IPVER_IPV6
L2RETRIES
20
1 through 255
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60 seconds
0 to 77600 (12hrs)
RETRYPROBE
19
1 through 255
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through
224000
SPEEDK
NOT_SET
0 through 4,000,000,000
SRCIPADDR2
0.0.0.1
Any 36-character string
SRCIPPORT1
1024
0 through 65534
STARTUP_OFF
3
STARTUP_ON
TXWINDOW
7
2 through 25
V6DESTIPADDR
0000:0000:0000:
0000:0000:0000:
0000:0000
Any 45-character string
V6SRCIPADDR
0000:0000:0000:
0000:0000:0000:
0000:0000
Any 45-character string
1. This is a required modifier.
2. This is a required modifier. See the TCP/IP Configuration and Management Manual, TCP/IP (Parallel Library)
Configuration and Management Manual, or TCP/IPv6 Configuration and Management Manual for IP address
syntax.
Expand Configuration and Management Manual—523347-008
14 -20
PEXQMATM Modifiers
Configuring Multi-Line Paths
PEXQMATM Modifiers
The disk file $SYSTEM.SYSnn.PEXQMATM defines modifiers for Expand-over-ATM
lines in multi-line paths. Table 14-6 lists the default value and range of values for each
modifier in this profile, if applicable. For modifiers that are mutually exclusive, a check
mark (3) is shown in the “Default Value” column to indicate which modifier is present in
the profile.
Table 14-7. PEXQMATM Modifiers
Modifier
Default Value
Range of Values
AFTERMAXRETRIES_DOWN
OFF
ON or OFF
AFTERMAXRETRIES_PASSIVE
3
ON or OFF
ASSOCIATEDEV1
None
Any 8-character string
CONNECTTYPE_ACTIVEANDPASSIVE
3
ON or OFF
ATMSEL2
%H80
0 through %HFF
CALLTYPE_PVC3
3
CALLTYPE_SVC2
CONNECTTYPE_PASSIVE
DESTATMADDR 2
(ISONSAP:
%H00...)
Any valid ISO NSAP ATM
address
DOWNIFBADQUALITY_ON
DOWNIFBADQUALITY_OFF
3
FRAMESIZE
132
64 through 2047
L2RETRIES
20
1 through 255
LINEPRIORITY
1
1 through 9
LINETF
0
0 through 186
MAXRECONNECTS
0
0 through 32767
PVCNAME3
None
Any 8-character string
QUALITYTHRESHOLD
0
0 to 99
QUALITYTIMER
60 seconds
0 to 77600 (12hrs)
RXWINDOW
7
2 through 15
SPEED
0
0 or 1200 through 224000
SPEEDK
NOT_SET
0 through 4,000,000,000
STARTUP_OFF
3
STARTUP_ON
TXWINDOW
7
2 through 25
1. This is a required modifier.
2. This modifier is required for Expand-over-ATM line-handler processes that use SVC connections.
3. This modifier is required for Expand-over-ATM line-handler processes that use PVC connections.
Expand Configuration and Management Manual—523347-008
14 -21
Configuring Multi-Line Paths
Expand Configuration and Management Manual—523347-008
14 -22
PEXQMATM Modifiers
Part III. Subsystem Control
Facility (SCF)
Part III consists the following sections, which describe the Subsystem Control Facility
(SCF) interface to the Expand subsystem:
Section 15
Subsystem Control Facility (SCF) Commands
Section 16
Tracing
Expand Configuration and Management Manual—523347-008
Part III. Subsystem Control Facility (SCF)
Expand Configuration and Management Manual—523347-008
15
Subsystem Control Facility (SCF)
Commands
This section describes the Subsystem Control Facility (SCF) interface to the Expand
subsystem and provides SCF command syntax. You should refer to the SCF
Reference Manual for G-Series RVUs for general information about running SCF.
Topics described in this section include the following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Overview of the Expand Subsystem SCF Interface on page 15-2
SCF and the WAN Subsystem on page 15-7
SCF and the SLSA Subsystem on page 15-8
ABORT Command on page 15-8
ACTIVATE Command on page 15-9
ALTER Command on page 15-10
ALTER DEVICE Command on page 15-10
ALTER PATH Command on page 15-11
ALTER LINE Command on page 15-12
ALTER PROCESS Command on page 15-21
DELETE ENTRY Command on page 15-23
INFO Command on page 15-24
INFO PATH Command on page 15-25
INFO LINE Command on page 15-29
INFO PROCESS Command on page 15-47
PRIMARY PROCESS Command on page 15-65
PROBE PROCESS Command on page 15-67
START Command on page 15-69
STATS Command on page 15-70
STATS PATH Command on page 15-70
STATS PATH NODE Command on page 15-76
STATS PROCESS Command on page 15-91
STATUS Command on page 15-95
STATUS PATH Command on page 15-95
STATUS LINE Command on page 15-97
STOP Command on page 15-105
TRACE Command on page 15-106
VERSION Command on page 15-111
VERSION PROCESS $ZEXP Command on page 15-112
VERSION PROCESS $NCP Command on page 15-112
VERSION PROCESS LINE Command on page 15-113
Expand Configuration and Management Manual—523347-008
15- 1
Overview of the Expand Subsystem SCF Interface
Subsystem Control Facility (SCF) Commands
Overview of the Expand Subsystem SCF
Interface
The Expand subsystem SCF interface is provided to configure, control, and display
information about configured objects within the Expand subsystem. This subsection
provides information on the following topics:
•
•
•
•
•
Expand Subsystem Objects
Object States
SCF Commands and Objects
Sensitive and Nonsensitive Commands
Time Values
Expand Subsystem Objects
The SCF objects for the Expand subsystem correspond to process components within
the subsystem. There are four Expand object types:
•
•
•
•
LINE
PATH
PROCESS
ENTRY
Figure 15-1 shows the Expand subsystem objects supported by SCF and their
hierarchical order.
Figure 15-1. Expand Subsystem Object Hierarchy
PROCESS
PATH
ENTRY
LINE
CDT 051.CDD
LINE and PATH Objects
A line is a single communications link between two adjacent nodes in a network; a
path is a logical connection between two adjacent nodes that can consist of multiple
lines.
Single-Line Expand Line-Handler Processes
An Expand line-handler process that manages a single line consists of a single logical
device that manages both path and line functions. The path and line functions can be
defined as follows:
Expand Configuration and Management Manual—523347-008
15- 2
Subsystem Control Facility (SCF) Commands
•
•
Expand Subsystem Objects
The path function corresponds to the functions defined by Layers 3 and 4 of the
Open Systems Interconnection (OSI) Reference Model. You specify the PATH
object when you want to display Layer 3 and 4 information or alter Layer 3 and 4
attributes for a single-line Expand line-handler process.
The line function corresponds to the functions defined by Layer 2 of the OSI
Reference Model. You specify the LINE object when you want to display Layer 2
information or alter Layer 2 attributes for a single-line Expand line-handler process.
Note. For more information about how the Expand subsystem relates to the OSI Reference
Model, refer to Expand Subsystem and the OSI Reference Model on page 18-9.
Multi-Line Paths
A multi-line path consists of multiple logical devices: a single logical device manages
the path function (called a path logical device) and separate logical devices (called
line logical devices) manage each of the lines in the path.
You must specify the PATH object when you want to manage a path logical device and
the LINE object when you want to manage a line logical device. The LINE object is
subordinate to the PATH object when it describes a line logical device.
Note. SCF will return an error message if you try to use the LINE object to manage a path
logical device or the PATH object to manage a line logical device.
Multi-CPU Paths
A multi-CPU path consists of up to 16 individual Expand paths, including multi-line
paths. Each Expand line-handler process (or multi-line path) that is a member of a
multi-CPU path is configured in a different processor.
You use SCF commands to manage multi-CPU paths in the same way that you use
SCF commands to manage single-line Expand line-handler processes.
Expand-Over-NAM, IP, ATM, ServerNet, X.25, and FOX Connections
Expand-over-NAM, Expand-over-IP, Expand-over-ATM, Expand-over-ServerNet,
Expand-over-X.25, and Expand-over-FOX line-handler processes use the Layer 2 (line
function) services of another process. For example, an Expand-over-X.25 line-handler
process uses the Layer 2 services provided by an X25AM line-handler process.
LINE and PATH Object Names
A LINE object name can be the device name of an Expand line-handler process that
manages a single line, or it can be the device name of a line logical device (a line in a
multi-line path).
A PATH object name can be the device name of an Expand line-handler process that
manages a single line, or it can be the device name of a path logical device.
Expand Configuration and Management Manual—523347-008
15- 3
Subsystem Control Facility (SCF) Commands
Object States
The following are some typical device names:
$SYS1
An Expand line-handler process that manages a
single line to the node named \SYS1
$PATH
A path logical device
$LINE1, $LINE2, and so on
Line logical devices
PROCESS Object
The PROCESS object type may refer to the Expand manager process ($ZEXP), the
network control process ($NCP), or an Expand line-handler process.
ENTRY Object
The ENTRY object type identifies an entry in the network routing table (NRT). You use
the ENTRY object to delete a system name from the NRT if the system associated with
that name is not connected to the network. The ENTRY object type applies only to the
object name $NCP.
Object States
Objects can have operational states, such as STOPPED or STARTED. The exact
sequence of states an object goes through varies from object to object and from
subsystem to subsystem. Some subsystem commands recognize only a few states.
Applicable states are discussed with each subsystem description.
The operational state of an object at a given instant is important. For example, certain
commands have no effect on objects when those objects are in a particular state but
can affect the object when it is in another state.
The following states are recognized by the Expand subsystem:
State
Description
ABORTING
The object is being aborted. Typically, this state is triggered by an ABORT
command or by a device malfunction. In this state, no new links are
allowed and drastic measures are applied to reach the STOPPED state.
This state is irrevocable.
DIAGNOSING
This state is entered when the object is being diagnosed by a diagnostic
process.
STARTED
The object is initialized and ready for normal data traffic.
STARTING
The object is being initialized and is attempting to start.
STOPPED
The object is not ready for normal operations. STOPPED is equivalent to
down, not ready, or killed.
Expand Configuration and Management Manual—523347-008
15- 4
SCF Commands and Objects
Subsystem Control Facility (SCF) Commands
SCF Commands and Objects
Table 15-1 lists the SCF commands and objects that are applicable to the Expand
subsystem.
Table 15-1. Expand Commands and Object Types
Object Types
Command
PROCESS
(Line Handler)
PROCESS
($NCP)
ENTRY
PATH
LINE
X
X
X
X
X
X
X
X
X
X
STATUS
X
X
STOP
X
X
X
X
ABORT
ACTIVATE
X
ALTER
X
DELETE
X
INFO
PRIMARY
X
X
PROBE
X
X
START
STATS
X
TRACE
VERSION
X
X
X
Sensitive and Nonsensitive Commands
SCF commands are either sensitive or nonsensitive. Sensitive commands can
change the state or configuration of subsystem objects, start or stop tracing, or change
the values of statistics counters; they can cause communications to cease if improperly
used. Nonsensitive commands request information or status but do not affect
operation. The use of sensitive commands is limited to the following user IDs:
•
•
Members of the super group (group ID 255)
Members of the user group that owns the process to which the command is sent
Expand Configuration and Management Manual—523347-008
15- 5
Wild-Card Support
Subsystem Control Facility (SCF) Commands
Table 15-2 lists the sensitive and nonsensitive Expand SCF commands.
Table 15-2. Sensitive and Nonsensitive Expand SCF Commands
Sensitive Commands
Nonsensitive Commands
ABORT
INFO
ACTIVATE
PROBE
ALTER
STATS (without the RESET option)
DELETE
STATUS
PRIMARY
VERSION
START
STATS (with the RESET option)
STOP
TRACE
Wild-Card Support
Object name templates (wild cards) are supported for most WAN subsystem SCF
commands as described in the SCF Reference Manual for G-Series RVUs.
Time Values
The variable time is used for attributes that require a time interval to be specified. The
syntax of time is
HH:MM:SS.hh
where HH is an integer that specifies hours, MM is an integer that specifies minutes,
SS is an integer that specifies seconds, and hh is an integer that specifies hundredths
of a second. The attribute descriptions in this section provide the range of values that
are valid for that attribute.
In the displays generated by the INFO command, HH is an integer in the range 0
through 24. MM and SS are integers in the range 0 through 60, and hh is an integer in
the range 0 through 99. For example, 5:27.02 is 5 minutes, 27 seconds, and 2
hundredths of a second.
Expand Configuration and Management Manual—523347-008
15- 6
Subsystem Control Facility (SCF) Commands
SCF and the WAN Subsystem
SCF and the WAN Subsystem
On NonStop S-series servers, you use the SCF interface to the WAN subsystem to
create $NCP and the Expand line-handler processes. You can also use the SCF
interface to the WAN subsystem to perform certain network-management tasks. The
SCF interface to the WAN subsystem is described in the WAN Subsystem
Configuration and Management Manual.
The following list explains when to use the SCF interface to the Expand subsystem
versus when to use the SCF interface to the WAN subsystem:
•
•
•
•
Use the SCF interface to the WAN subsystem to add $NCP and the Expand linehandler processes to the system.
You can use either the SCF interface to the Expand subsystem or the SCF
interface to the WAN subsystem to change modifier values for Expand line-handler
processes and $NCP. Consider the following when choosing which SCF interface
to use:
°
Changes made with the SCF interface to the Expand subsystem are temporary
(they do not remain across system loads) while changes made with the SCF
interface to the WAN subsystem are permanent (they do remain across system
loads).
°
You can change any Expand modifier using the SCF interface to the WAN
subsystem (ALTER DEVICE command).
°
You can change most, but not all, Expand modifiers using the SCF interface to
the Expand subsystem (ALTER LINE and ALTER PATH commands). Most
Expand modifiers have corresponding attribute names in Expand SCF.
°
Certain Expand SCF attributes do not correspond to Expand modifiers. You
can change these attribute values only by using the SCF interface to the
Expand subsystem.
°
Use the Expand subsystem STOP LINE or STOP PATH command before you
change attribute values using the ALTER LINE or ALTER PATH command.
°
Use the WAN subsystem STOP DEVICE command to stop an Expand linehandler process before you change modifier values using the ALTER DEVICE
command.
The SCF interface to the WAN subsystem treats Expand line-handler processes
and $NCP as devices (DEVICE object). It does not provide LINE, PATH,
PROCESS, or ENTRY objects for the Expand subsystem. Do not confuse the WAN
subsystem PATH and PROCESS objects with the Expand subsystem PATH and
PROCESS objects.
Use the WAN subsystem START DEVICE command to start an Expand linehandler process in the primary and backup processors. Use the Expand
subsystem START PATH or START LINE command to start path and line functions
once the Expand line-handler process is started.
Expand Configuration and Management Manual—523347-008
15- 7
Subsystem Control Facility (SCF) Commands
•
SCF and the SLSA Subsystem
Use the Expand subsystem STOP PATH or STOP LINE command before you use
the STOP DEVICE command to stop the Expand line-handler process in the
primary and backup processors.
For a complete comparison of the Expand and WAN subsystem SCF interfaces, refer
to Appendix C, Expand and WAN SCF Comparison.
SCF and the SLSA Subsystem
For information on the management of the ATMSAP connection object by the SCF
ABORT, ADD, ALTER, DELETE, INFO, NAMES, START, STATS, STATUS, and STOP
commands. refer to the LAN Configuration and Management Manual.
ABORT Command
The ABORT command terminates the operation of LINE or PATH objects as quickly as
possible—only enough processing is done to ensure the security of the subsystem.
The objects are left in the STOPPED state. ABORT is a sensitive command.
The ABORT command syntax is as follows:
ABORT { PATH path-name | LINE line-name }
PATH path-name
indicates the device name of a path.
LINE line-name
indicates the device name of a line.
Considerations
•
•
•
•
If a line is specified, the execution of this command terminates activity on the
specified line.
If a path is specified, the execution of this command terminates activity on all lines
associated with the specified path.
To terminate activity nondisruptively, use the STOP Command. The STOP
command terminates the operation of a LINE or PATH object only after all activity
on the line or path stops. The ABORT command halts all activity abruptly: your files
and listings could be inconsistent or incomplete if aborted when files are open over
a line or path.
The lines or paths are placed in the STOPPED state and the communications line
interface processor (CLIP) remains loaded if lines or paths are for a ServerNet
wide area network (SWAN) concentrator.
Expand Configuration and Management Manual—523347-008
15- 8
Subsystem Control Facility (SCF) Commands
•
Examples
You can abort several lines or paths with a single ABORT command by specifying
multiple PATH or LINE objects using parentheses as follows:
PATH ( path-name , path-name [ , path-name ] ...)
LINE ( line-name , line-name [ , line-name ] ... )
Examples
The first SCF command aborts one line and the second SCF commands aborts two
lines:
-> ABORT LINE $LHCMP2
-> ABORT LINE ($LHCMP2,$LHCMP3)
The first SCF command aborts one path and the second SCF command aborts two
paths:
-> ABORT PATH $PTS
-> ABORT PATH ($PTS,$PTS2)
ACTIVATE Command
The ACTIVATE command initiates an immediate rebalance of a multi-CPU path to a
specified neighbor system. ACTIVATE is a sensitive command.
The ACTIVATE command syntax is as follows:
ACTIVATE PROCESS $NCP, REBAL [ system-name ]
system-name
specifies the multi-CPU path to be rebalanced. If no system name is specified, all
multi-CPU paths on the system are rebalanced.
Considerations
You can schedule automatic rebalancing of multi-CPU paths by using the ALTER
PROCESS command.
Example
The following SCF command initiates the immediate rebalance of the multi-CPU path
to the system named \NODEA:
-> ACTIVATE PROCESS $NCP, REBAL \NODEA
Expand Configuration and Management Manual—523347-008
15- 9
Subsystem Control Facility (SCF) Commands
ALTER Command
ALTER Command
The ALTER command changes the values for PATH object types, LINE object types,
and the PROCESS $NCP object type. ALTER is a sensitive command.
The ALTER command syntax is as follows:
ALTER { PROCESS $NCP | PATH path-name | LINE line-name }
ALTER DEVICE Command
The WAN subsystem ALTER DEVICE command changes the values of a data
communications subsystem object.
The ALTER DEVICE command changes only the specified attributes of the target
object. See the WAN Subsystem Configuration and Management Manual for detailed
information on this command.
The ALTER DEVICE command has the following syntax (you must specify one or more
attributes):
ALTER DEVICE $ZZWAN.#device-name
[ , ADAPTER conc-name
]
[ , CLIP clip-num
]
[ , HIGHPIN "ON" | "OFF"
]
[ , IOPOBJECT object-file-name
]
[ , LINE line-num
]
[ , modifier-keyword [ modifier-value ]
]...
[ , PATH path-name
]
[ , [ RECSIZE | RSIZE ] max-rex-size
]
[ , RESET
[ ( modifier-keyword [ modifier-keyword ... ] ) ] ]
[ , TYPE ( type , sub-type )
]
Considerations
The default value for HIGHPIN is "ON" because HP expects that no one would ever
want a line handler to run at low pin. However, if you want to change this value to
"OFF" you must do so explicitly by issuing the following commands to SCF:
1->
2->
3->
4->
5->
abort line $lh01
stop device $zzwan.#lh01
alter device $zzwan.#lh01, highpin off
start device $zzwan.#lh01
start line $lh01
Note that in Step 1, you need to stop the line in order to stop the device, and in Step 2,
you need to stop the device in order to alter the device.
Expand Configuration and Management Manual—523347-008
15 -10
Subsystem Control Facility (SCF) Commands
ALTER PATH Command
ALTER PATH Command
The ALTER PATH command is described below. The PATH object type takes the
following form:
PATH path-name attribute-spec [, attribute-spec ] ...
where path-name is the device name of a path and attribute-spec is one of the
following attribute name and value combinations:
[
[
[
[
[
[
[
[
[
[
[
[
COMPRESS { ON | OFF } ]
L4CONGCTRL { ON | OFF } ]
L4EXTPACKETS { ON | OFF } ]
L4RETRIES integer ]
L4SENDWINDOW n]
L4TIMEOUT time ]
NEXTSYS system-number ]
OSSPACE integer ]
OSTIMEOUT time ]
PATHBLOCKBYTES integer ]
PATHPACKETBYTES integer ]
SUPERPATH { ON | OFF } ]
Table 15-3 lists the path attributes that have corresponding profile modifiers.
Table 15-3. ALTER PATH Attributes and Corresponding Profile Modifiers
SCF Attribute
Profile Modifier
COMPRESS
COMPRESS_OFF/COMPRESS_ON
L4CONGCTRL
L4CONGCTRL_OFF/L4CONGCTRL_ON
L4EXTPACKETS
L4EXTPACKETS_OFF/L4EXTPACKETS_ON
L4RETRIES
L4RETRIES n
L4SENDWINDOW
L4SENDWINDOW n
L4TIMEOUT
L4TIMEOUT n
NEXTSYS
NEXTSYS n
OSSPACE
OSSPACE n
OSTIMEOUT
OSTIMEOUT n
PATHBLOCKBYTES
PATHBLOCKBYTES n
PATHPACKETBYTES
PATHPACKETBYTES n
SUPERPATH
SUPERPATH_OFF/SUPERPATH_ON
For detailed information about each path attribute, refer to the description of the
corresponding profile modifier in Section 17, Expand Modifiers.
Expand Configuration and Management Manual—523347-008
15 -11
Subsystem Control Facility (SCF) Commands
Considerations
Considerations
•
You can alter several paths with a single ALTER command by specifying multiple
PATH objects using parentheses as follows:
-> PATH ( path-name , path-name [ , path-name ] ... )
Examples
The following SCF command changes the value of the path’s NEXTSYS attribute to
system 100 and the value of its TIMERINACTIVITY attribute to 9 minutes and
30 seconds:
-> ALTER PATH $PATH1, NEXTSYS 100, TIMERINACTIVITY 9:30.00
The following SCF command changes the value of the TIMERINACTIVITY attribute to
10 minutes for two different paths:
-> ALTER PATH ($PATH2,$PATH3), TIMERINACTIVITY 10:00.00
ALTER LINE Command
The ALTER LINE command is described below. The LINE object type takes the
following form:
LINE line-name attribute-spec [, attribute-spec ]...
where line-name is the device name of a line and attribute-spec is one of
the following attribute name and value combinations:
Expand Configuration and Management Manual—523347-008
15 -12
Subsystem Control Facility (SCF) Commands
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
ALTER LINE Command
AFTERMAXRETRIES { DOWN | PASSIVE } ]
ASSOCIATEDEV device-name ]
ASSOCIATESUBDEV subdevice-name ]
ATMSEL selector-byte ]
CALLTYPE { PVC | SVC | ATMSAP} ]
CLBDWNLOADRETRIES integer ]
CLBDWNLOADTIMR time ]
CLBIDLETIMER time ]
CLOCKMODE { DTE | DCE } ]
CLOCKSPEED { 600 | 1200 | 2400 | 4800 | 9600 |
19200 | 38400 | 56000 | 115200 } ]
CONNECTTYPE { ACTIVEANDPASSIVE | PASSIVE } ]
DELAY time ]
DESTATMADDR atm-address ]
DESTIPADDR ip-address ]
DESTIPPORT integer]
DOWNIFBADQUALITY { ON | OFF } ]
DSRTIMER time ]
FLAGFILL { ON | OFF } ]
IDLETIMEOUT time ]
INTERFACE { RS232 | RS422 } ]
IPVER (IPv4 | IPv6 } ]
L2DISCARDONRESET { ON | OFF } ]
L2RETRIES integer ]
L2TIMEOUT time ]
LIFNAME lif-name ]
LINEPRIORITY 1-9 ]
LINETF integer ]
MAXRECONNECTS integer ]
PROGRAM file-spec ]
PVCNAME pvc-name ]
QUALITYTHRESHOLD 0 to 99 ]
QUALITYTIMER time ]
RETRYPROBE integer ]
RXWINDOW integer ]
SPEED{1.2 | 2.4 | 4.8 | 9.6 | 19.2 | 56 | 64 | 128 | 224 }]
SPEEDK bps or symbolic names such as ETHER10
SRCIPADDR ip-address ]
SRCIPPORT integer]
TIMERBIND time ]
TIMERINACTIVITY time ]
TIMERPROBE time ]
TIMERRECONNECT time ]
TXWINDOW integer ]
V6DESTIPADDR ipv6-address ]
V6SRCIPADDR ipv6-address ]
Expand Configuration and Management Manual—523347-008
15 -13
Subsystem Control Facility (SCF) Commands
ALTER LINE Command
Table 15-4 lists the line attributes that have corresponding profile modifiers.
Table 15-4. ALTER LINE Attributes and Corresponding Profile
Modifiers (page 1 of 2)
SCF Attribute
Profile Modifier
AFTERMAXRETRIES
AFTERMAXRETRIES_DOWN/
AFTERMAXRETRIES_PASSIVE
ASSOCIATEDEV
ASSOCIATEDEV $dev-name
ASSOCIATESUBDEV
ASSOCIATESUBDEV #n
ATMSEL
ATMSEL n
CALLTYPE
CALLTYPE_PVC/CALLTYPE_SVC/CALLTYPE_ATMSAP
CLOCKMODE
CLOCKMODE_DCE/CLOCKMODE_DTE
CLOCKSPEED
CLOCKSPEED_600/CLOCKSPEED_1200
CLOCKSPEED_2400/CLOCKSPEED_4800
CLOCKSPEED_9600/CLOCKSPEED_19200
CLOCKSPEED_38400/CLOCKSPEED_56000
CLOCKSPEED_115200
CONNECTTYPE
CONNECTTYPE_ACTIVEANDPASSIVE/
CONNECTTYPE_PASSIVE
DELAY
DELAY n
DESTATMADDR
DESTATMADDR n
DESTIPADDR
DESTIPADDR n
DESTIPPORT
DESTIPPORT n
DOWNIFBADQUALITY
DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF
FLAGFILL
FLAGFILL_OFF/ FLAGFILL_ON
INTERFACE
INTERFACE_RS232/INTERFACE_RS422
IPVER
IPVER_IPV4/IPVER_IPV6
L2DISCARDONRESET
L2DISCARDONRESET_OFF/L2DISCARDONRESET_ON
L2RETRIES
L2RETRIES n
L2TIMEOUT
L2TIMEOUT n
LIFNAME
LIFNAME n
LINEPRIORITY
LINEPRIORITY n
LINETF
LINETF n
MAXRECONNECTS
MAXRECONNECTS n
PROGRAM
PROGRAM n
PVCNAME
PVCNAME n
QUALITYTHRESHOLD
QUALITYTHRESHOLD n
QUALITYTIMER
QUALITYTIMER n
RETRYPROBE
RETRYPROBE n
Expand Configuration and Management Manual—523347-008
15 -14
Subsystem Control Facility (SCF) Commands
ALTER LINE Command
Table 15-4. ALTER LINE Attributes and Corresponding Profile
Modifiers (page 2 of 2)
SCF Attribute
Profile Modifier
RXWINDOW
RXWINDOW n
SPEED
SPEED n
SPEEDK
SPEEDK n
SRCIPADDR
SRCIPADDR n
SRCIPPORT
SRCIPPORT n
TIMERINACTIVITY
TIMERINACTIVITY n
TIMERPROBE
TIMERPROBE n
TIMERRECONNECT
TIMERRECONNECT n
TXWINDOW
TXWINDOW n
V6DESTIPADDR
V6DESTIPADDR n
V6SRCIPADDR
V6SRCIPADDR n
For detailed information about the line attributes that have corresponding profile
modifiers, refer to the description of the corresponding profile modifier in Section 17,
Expand Modifiers.
Line attributes that do not have corresponding profile modifiers are as follows:
CLBDWNLOADRETRIES integer
specifies the maximum number of times that the Expand line-handler process will
try to download a communications line interface processor (CLIP). This attribute
applies to ServerNet wide area network (SWAN) concentrators. The valid range for
this attribute is 2 to 255. The default is 3.
CLBDWNLOADTIMR time
specifies the time interval that the Expand line-handler process will wait for the
successful completion of a communications line interface processor (CLIP)
download operation. This attribute applies to ServerNet wide area network (SWAN)
concentrators only. The time interval is specified in the format described in Time
Values on page 15-6.
The valid range for this attribute is 30.00 seconds to 5:27.67 minutes. The default
is 30.00 seconds.
CLBIDLETIMER time
specifies the time interval that the Expand line-handler process will wait before
sending successive status probes to the communications line interface processor
(CLIP). A value of 0 indicates that no status probe will be issued. This attribute
applies to ServerNet wide area network (SWAN) concentrators only. The time
interval is specified in the format described in Time Values on page 15-6.
Expand Configuration and Management Manual—523347-008
15 -15
ALTER LINE Command
Subsystem Control Facility (SCF) Commands
The valid range for this attribute is 0 to 5:27.67 minutes. The default is 10.00
seconds.
DSRTIMER time
specifies the amount of time that the line-handler process should wait after a Data
Set Ready (DSR) signal from the modem has shut off before it returns a modem
status message. This attribute applies to ServerNet wide area network (SWAN)
concentrators only. The time interval is specified in the format described in Time
Values on page 15-6.
The valid range for this attribute is 1.0 seconds to 5:27.67 minutes. The default is
1.0 second.
IDLETIMEOUT time
specifies the time interval to wait after modem loss before timing out following the
loss of a Data Set Ready (DSR) signal from the modem. The time interval is
specified in the format described in Time Values on page 15-6.
This attribute applies only to intelligent modems. For lines attached to a ServerNet
wide area network (SWAN) concentrator, IDLETIMEOUT is used as the idle
transmit timer and idle receive timer for Layer 2 running on the communications
line interface processor (CLIP).
The valid range for this attribute is 0.50 seconds to 5:27.67 minutes. The default is
10 seconds.
RETRYPROBE integer
specifies the number of times the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will retry its probe of the network access
method (NAM), or how many times the Expand-over-IP or Expand-over-ATM linehandler process will retry the probe of the remote Expand-over-IP or Expand-overATM line-handler process before declaring the network unavailable. A value of 0
indicates that timeouts are ignored and the connect state is maintained.
The valid range for this attribute is 1 to 255. The default values are as follows:
Expand-over-NAM lines:
20
Expand-over-ServerNet lines
10
Expand-over-FOX lines:
10
Expand-over-IP lines:
19
Expand-over-ATM lines:
19
Expand Configuration and Management Manual—523347-008
15 -16
ALTER LINE Command
Subsystem Control Facility (SCF) Commands
TIMERBIND time
specifies the time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait for a completion of its bind request
to the NAM process. The time interval is specified in the format described in Time
Values on page 15-6.
The TIMERBIND attribute does not apply to Expand-over-IP and Expand-over-ATM
line-handler processes. A value of 0 indicates an indefinite interval (no timer).
The valid range for this attribute is 0 to 9:06:07.00 hours. The default value for
Expand-over-NAM lines is 30.00 seconds; the default value for Expand-overServerNet lines is 60.00 seconds the default value for Expand-over-FOX lines is
60.00 seconds.
TIMERINACTIVITY time
specifies the time interval that the Expand-over-NAM line-handler process will wait
during a period of inactivity before requesting disconnection from the network
service provided by the network access method (NAM) process, or the time
interval the Expand-over-IP line-handler process will wait during a period of user
data inactivity before suppressing non-essential maintenance traffic (netmaps) so
that an external process can disconnect from the network. In both cases, the line
remains ready and the next user data traffic brings the line out of the inactive state.
This attribute is applicable only for Expand-over-IP, Expand-over-X.25, and
Expand-over-SNAX line-handler processes. The valid range for this attribute is 0 to
32767 seconds. The default value for Expand-over-X.25 and Expand-over-SNAX
lines is 15:00 minutes, the default value for Expand-over-IP lines is 0 (no timer).
TIMERPROBE time
specifies the time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait to send out a probe to obtain the
status of the NAM process, or the time interval that the Expand-over-IP or Expandover-ATM line-handler process will wait to probe the remote Expand-over-IP or
Expand-over-ATM line-handler process. The time interval is specified in the format
described in Time Values on page 15-6.
Probes will continue to be sent out the number of times specified by the
RETRYPROBE attribute. If the TIMERPROBE/RETRYPROBE cycle expires
without a returned status, then the Expand-over-NAM, Expand-over-ServerNet,
Expand-over-FOX, Expand-over-ATM, or Expand-over-IP line-handler process
declares the network unavailable.
The valid ranges for this attribute are as follows:
Expand-over-IP lines:
1 through 32767
Expand-over-ATM lines:
1 through 32767
Expand-over-X.25 lines:
1 through 32767
Expand Configuration and Management Manual—523347-008
15 -17
Considerations
Subsystem Control Facility (SCF) Commands
Expand-over-SNA lines:
1 through 32767
Expand-over-ServerNet lines:
30 through 32767
Expand-over-FOX lines:
30 through 32767
The default values for this attribute are as follows:
Expand-over-IP lines:
1
Expand-over-ATM lines:
1
Expand-over-X.25 lines:
300
Expand-over-SNA lines:
300
Expand-over-ServerNet lines:
30
Expand-over-FOX lines:
30
TIMERRECONNECT time
specifies the time interval that the Expand-over-NAM, Expand-over-ATM, Expandover-IP, Expand-over-ServerNet, or Expand-over-FOX line-handler process will
wait for a connection request to succeed. The range does not include 0. The time
interval is specified in the format described in Time Values on page 15-6.
Expand line-handler processes on opposite ends of an X25AM line should use
different values for TIMERRECONNECT.
The valid range for this attribute is 30.00 through 32767 seconds for Expand-overIP and Expand-over-ATM lines and 0 through 32767 seconds for Expand-overNAM, Expand-over-ServerNet, and Expand-over-FOX lines.
The default value for this attribute is 30.00 seconds for Expand-over-NAM,
Expand-over-ATM lines, and Expand-over-IP lines, and 60.00 seconds for Expandover-ServerNet and Expand-over-FOX lines.
Considerations
You can alter several lines with a single ALTER command by specifying multiple LINE
objects using parentheses as follows:
-> LINE ( line-name , line-name [ , line-name ] ... )
Table 15-5 specifies the applicable ALTER LINE attributes for the different types of
line-handler processes.
Expand Configuration and Management Manual—523347-008
15 -18
Considerations
Subsystem Control Facility (SCF) Commands
Table 15-5. ALTER LINE Attributes (page 1 of 2)
Directand
SatelliteConnect
ExpandOverNAM
Expand-OverServerNet, and
Expand-Over-FOX
ExpandOver-IP
ExpandOverATM
AFTERMAXRETRIES
X
X
X
X
ASSOCIATEDEV
X
X
X
X
Attribute
ASSOCIATESUBDEV
X
ATMSEL
X
CALLTYPE
X
CLBDWNLOADRETRIES
X
CLBDWNLOADTIMR
X
CLBIDLETIMER
X
CLOCKMODE
X
CLOCKSPEED
X
CONNECTTYPE
X
DELAY
X
X
DESTATMADDR
X
DESTIPADDR
X
DESTIPPORT
X
DOWNIFBADQUALITY
X
DSRTIMER
X
FLAGFILL
X
IDLETIMEOUT
X
INTERFACE
X
X
IPVER
X
X
L2DISCARDONRESET
X
L2RETRIES
X
L2TIMEOUT
X
X
X
LIFNAME
X
LINEPRIORITY
X
X
X
X
X
LINETF
X
X
X
X
X
X
X
X
X
MAXRECONNECTS
PROGRAM
X
PVCNAME
X
QUALITYTHRESHOLD
X
X
X
QUALITYTIMER
X
X
X
Expand Configuration and Management Manual—523347-008
15 -19
Examples
Subsystem Control Facility (SCF) Commands
Table 15-5. ALTER LINE Attributes (page 2 of 2)
Directand
SatelliteConnect
ExpandOverNAM
Expand-OverServerNet, and
Expand-Over-FOX
ExpandOver-IP
ExpandOverATM
RETRYPROBE
X
X
X
X
RXWINDOW
X
X
Attribute
SPEED
X
X
X
X
X
SPEEDK
X
X
X
X
X
SRCIPADDR
X
SRCIPPORT
X
TIMERBIND
X
TIMERINACTIVITY
X
TIMERPROBE
X
TIMERRECONNECT
TXWINDOW
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
V6DESTIPADDR
X
V6SRCIPADDR
X
Examples
The following SCF command changes the value of the line’s L2TIMEOUT attribute to
10 seconds:
-> ALTER LINE $LINEX, L2TIMEOUT 10.00
The following SCF command disables the transmission of FLAGs when the linehandler process $LHBIT is in the idle state:
-> ALTER LINE $LHBIT, FLAGFILL OFF
The following SCF command changes the value of the TIMERPROBE attribute for two
different lines:
-> ALTER LINE ($LHX251,$LHX252), TIMERPROBE 4:30.50
Expand Configuration and Management Manual—523347-008
15 -20
Subsystem Control Facility (SCF) Commands
ALTER PROCESS Command
ALTER PROCESS Command
The ALTER PROCESS command changes the values of the attributes of the network
control process ($NCP). This command changes only the specified attributes of $NCP.
ALTER PROCESS is a sensitive command.
The ALTER PROCESS command for $NCP has the following syntax:
ALTER PROCESS $NCP attribute-spec [ attribute-spec ] ...
where attribute-spec for the PROCESS object type for $NCP has the following
attribute name and value combination:
[
[
[
[
[
[
[
[
[
[
[
ABORTTIMER time ]
AUTOREBAL { ON | OFF } ]
AUTOREBALTIME { time | ( time, start-time ) } ]
CONNECTTIME time ]
MAXCONNECTS integer ]
MAXTIMEOUTS integer ]
NETWORKDIAMETER integer ]
MSG43 { ON | OFF } ]
MSG46 { ON | OFF } ]
MSG48 { ON | OFF } ]
MSG49 { ON | OFF } ]
Table 15-6 lists the $NCP attributes that have corresponding profile modifiers.
Table 15-6. ALTER PROCESS Attributes and Corresponding Profile Modifiers
SCF Attribute
Profile Modifier
ABORTTIMER
ABORTTIMER n
CONNECTTIME
CONNECTTIME n
MAXCONNECTS
MAXCONNECTS n
MAXTIMEOUTS
MAXTIMEOUTS n
NETWORKDIAMETER
NETWORKDIAMETER n
For detailed information about the $NCP attributes that have corresponding profile
modifiers, refer to the description of the corresponding profile modifier in Section 6,
Configuring the Network Control Process.
$NCP attributes that do not have corresponding profile modifiers are as follows:
AUTOREBAL { ON | OFF }
enables (ON) or disables (OFF) automatic rebalancing of the multi-CPU paths on
the system. The time at which automatic rebalancing will occur is determined by
the AUTOREBALTIME attribute. The default value is ON.
Expand Configuration and Management Manual—523347-008
15 -21
Subsystem Control Facility (SCF) Commands
ALTER PROCESS Command
AUTOREBALTIME time | ( time, start-time )
determines when automatic rebalancing of multi-CPU paths on the system will
occur.
When time is specified, rebalancing will occur periodically at the time interval
specified starting after the command is executed.
When (time, start-time) is specified, rebalancing will occur periodically at the
time interval specified starting at the time of day specified in start-time. The
time of day must be specified using a 24-hour clock and the local time of the
system on which $NCP resides.
The format of time interval (time) and time of day (start-time) is as follows:
[DDD/]HH:MM:SS
where
[DDD/]
specifies the number of days and is an integer in the range 0 to 999. When
[DDD/] is specified in the starting time (start-time), it represents the
number of days that the specified time of day will be skipped before the first
automatic rebalancing will occur.
HH
specifies the hours and is an integer in the range 0 to 23.
MM
specifies the minutes and is an integer in the range 0 to 59.
SS
specifies seconds and is an integer in the range 0 to 59.
The default time interval is 1/0:0:0 (24 hours) and the default start time is 0:0:0
(midnight). The minimum time interval (time) is 15 minutes.
MSG43 { ON | OFF }
enables (ON) or disables (OFF) the reporting of event message 43 to the Event
Message Service (EMS) collector, $0. Event message 43 is equivalent to console
message 43. This is a critical message. It means that the connection to the
indicated system has been lost. The default value is OFF.
MSG46 { ON | OFF }
enables (ON) or disables (OFF) the reporting of event message 46 to the EMS
collector, $0. Event message 46 is equivalent to console message 46. This is not a
critical message. It means a connection has been made with the indicated remote
system. The default value is OFF.
Expand Configuration and Management Manual—523347-008
15 -22
Subsystem Control Facility (SCF) Commands
Example
MSG48 { ON | OFF }
enables (ON) or disables (OFF) the reporting of event message 48 to the EMS
collector, $0. Event message 48 is equivalent to console message 48. This is a
critical message. It means a change in processor status has occurred at the
indicated system. The default value is OFF.
MSG49 { ON | OFF }
enables (ON) or disables (OFF) the reporting of event message 49 to the EMS
collector, $0. Event message 49 is equivalent to console message 49. This is a
critical message. It means that the local $NCP has not received a status message
from $NCP at the indicated system for three time periods. The default value is
OFF.
Example
The following SCF command changes the maximum number of $NCP connect
requests to 10 and enables the reporting of event message 43 to the EMS collector,
$0:
-> ALTER PROCESS $NCP, MAXCONNECTS 10, MSG43 ON
DELETE ENTRY Command
The DELETE ENTRY command applies only to the network control process ($NCP).
The command removes system names from the network routing table (NRT) if the
systems are not connected within the network. DELETE ENTRY is a sensitive
command.
The DELETE ENTRY command has the following syntax:
DELETE ENTRY $NCP.{ * | system-number | \system-name }
* | system-number | \system-name
is the name or number of the system being deleted from the NRT. An asterisk (*)
specifies that all entries in the NRT should be deleted.
Considerations
An attempt to delete a system that is connected within the network results in the return
of an error message. To disconnect a system, use the ABORT PATH command
described earlier in this section.
Expand Configuration and Management Manual—523347-008
15 -23
Subsystem Control Facility (SCF) Commands
Examples
Examples
The following SCF command removes from the NRT all the names of systems that are
not connected within the network:
-> DELETE ENTRY $NCP.*
The following SCF command removes the system name \NODEA from the NRT if the
system named \NODEA is not connected within the network:
-> DELETE ENTRY $NCP.\NODEA
INFO Command
The INFO command displays the current or default attribute values for the specified
objects. INFO is a nonsensitive command.
The INFO command has the following syntax:
INFO [ / OUT file-spec / ]
{ PROCESS $NCP | PATH path-name | LINE line-name }
[ , DETAIL ]
/ OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
PATH path-name
indicates the device name of a path.
LINE line-name
indicates the device name of a line.
PROCESS $NCP
indicates the network control process ($NCP).
Expand Configuration and Management Manual—523347-008
15 -24
INFO PATH Command
Subsystem Control Facility (SCF) Commands
INFO PATH Command
The display for a path without the DETAIL option has the format as shown in
Example 15-1. The asterisk (*) indicates that the attribute can be altered using the
ALTER command, described earlier in this section.
Example 15-1. INFO PATH Command
-> INFO PATH $LHPATH
EXPAND Info Path
Name
$LHPATH
*Compress
ON
*Nextsys
#255
*L4Retries
3
*L4Timeout
0:00:20.00
Name
is the device name of the path.
Compress
shows whether Layer 4 data compression is enabled (ON) or disabled (OFF).
Nextsys
is the system number of the neighbor system on this path.
L4Retries
specifies the number of times the line-handler process will try an end-to-end (Layer
4) request before reporting an error.
L4Timeout
reports the time interval for the Layer 4 timer.
Example 15-2 shows the display format for a path with the DETAIL option. The asterisk
(*) indicates that the attribute can be altered using the ALTER command, described
earlier in this section.
Expand Configuration and Management Manual—523347-008
15 -25
Subsystem Control Facility (SCF) Commands
INFO PATH Command
Example 15-2. INFO PATH, DETAIL Command
-> INFO PATH $LHPATH, DETAIL
EXPAND
Detailed Info PATH $LHPATH
*Compress....
ON
*OStimeout... 0:00:03.00
*L4Timeout... 0:00:20.00
*L4ExtPackets
ON
Local
*PathBlockBytes
0
*PathPacketBytes
1024
*Nextsys........ #255 *OSspace..... 32767
*L4Retries......
3 *PathTF..
1
*L4SendWindow... 254
TimeFactor
1
*L4CongCtrl.....
ON *Superpath...
ON
Remote
Negotiated
Maximum
0
0
9180
0
0
9180
Compress
shows whether Layer 4 data compression is enabled (ON) or disabled (OFF).
Nextsys
is the system number of the neighbor system on this path.
OSspace
displays the maximum buffer size (in words) for storing out-of-sequence (OOS)
packets.
Please refer to the note under OSSPACE n on page 17-17 that explains why the
recommended setting for OSSPACE is to not specify it, but to let the default be
used.
OStimeout
reports the amount of time, in one-hundredth of a second increments, that OOS
packets are held before they are discarded. For example, an OStimeout value of
300 is equal to 5 minutes.
L4Retries
specifies the number of times the line-handler process will try an end-to-end (Layer
4) request before reporting an error.
PathTF
is the path time factor. PATHTF has a range of 0 to 186, with a default of 0 (unset).
If you set PATHTF, it overrides any other parameter (RSIZE, SPEED, SPEEDK, or
LINETF) in calculating the time factor for the path. When PATHTF is set for a multiline path, the line state and number of lines in the path are ignored and the
PATHTF setting is a constant value assigned to the time factor for the path. If
PATHTF is left unset (a zero value), this parameter is not used in setting the time
factor.
Expand Configuration and Management Manual—523347-008
15 -26
Subsystem Control Facility (SCF) Commands
INFO PATH Command
L4Timeout
reports the time interval for the Layer 4 timer.
L4SendWindow
is the maximum number of outstanding packet send requests in any single
transport connection.
TimeFactor
reports the current time factor for this path. The time factor is used by NCP when
calculating the best route between systems and represents the cost of using the
path. The lower the time factor, the more desirable the path.
The time factor is calculated based upon the parameters you have set. Previously,
path time-factor calculations made within a node were made using the device/line
settings (RSIZE, SPEED, and SPEEDK) and from looking at the aggregate values
of time factors for the line if the path was a multi-line path. As of G06.20, the two
direct time-factor settings (LINETF and PATHTF) can be applied to override the
RSIZE, SPEED, and SPEEDK calculations within a node.
If PATHTF is set to a nonzero value, the time factor and PATHTF will be the same.
If PATHTF is not set (zero), the TimeFactor field will display the time factor being
used by the path.
If a line in the path fails and PATHTF is not set (zero), $NCP updates its NETMAP
table to reflect the decrease in path bandwidth. Reactivation of the line updates the
NETMAP table to reflect the increase in bandwidth. If a communications hardware
device fails, $NCP updates its NETMAP table to reflect the decrease in bandwidth
for all lines connected to the failed device.
L4ExtPackets
shows whether the extended packet format is enabled (ON) or disabled (OFF).
Extended packet format uses a larger packet header, which can reduce throughput
on lower-speed lines. It can provide higher throughput and less OOS processing in
paths with multiple high-speed lines. This feature is negotiated between end
systems and should be enabled at both end systems.
L4CongCtrl
shows whether congestion control is enabled (ON) or disabled (OFF). Congestion
control is used to avoid bottlenecks and deadlocks. If the congestion control
feature is enabled on both ends of a connection, it is executed for traffic in both
directions. Traffic in a given direction is subject to congestion control if the sender
has congestion control enabled and the receiver supports it. The receiver does not
have to have the congestion control feature enabled in order to support it.
Expand Configuration and Management Manual—523347-008
15 -27
Subsystem Control Facility (SCF) Commands
Considerations
Superpath
reports ON if the path is configured to be a member of a multi-CPU path and OFF if
it is not. The Expand line-handler process at the other end of the path must be
configured with SUPERPATH_ON or the multi-CPU path feature will not be
enabled. You can display the current setting of the SUPERPATH attribute using the
STATUS PATH command.
PathBlockBytes
shows the multipacket frame parameters for these four fields:
Local
Currently configured local value
Remote
Most recent value from the remote path
Negotiated
Amount that is currently in use; the lesser of the Local
and Remote values
Maximum
Maximum value available on this path
PathPacketBytes
shows the variable packet parameters for these four fields:
Local
Currently configured local value
Remote
Most recent value from the remote path
Negotiated
Amount that is currently in use; the lesser of the Local and
Remote values
Maximum
Maximum value available on this path
Considerations
You can display information about several paths with a single INFO command by
specifying multiple PATH objects using parentheses as follows:
PATH ( path-name , path-name [ , path-name ] ... )
Expand Configuration and Management Manual—523347-008
15 -28
INFO LINE Command
Subsystem Control Facility (SCF) Commands
INFO LINE Command
The format of the INFO LINE display varies according to the line-handler process type.
The first three lines of the display are common for all line types. The rest of the lines
vary according to the line type.
Direct-Connect and Satellite-Connect Line-Handler Processes
For both direct-connect and satellite-connect line-handler processes, the display for a
LINE object without the DETAIL option has the format as shown in Example 15-3. The
asterisk (*) indicates an alterable attribute.
Example 15-3. INFO LINE Command, Direct- and Satellite-Connect Line-Handler
Processes
-> INFO LINE $SWNLBA1
EXPAND
Name
$SWNLBA1
Info
LINE
Address
*Delay
(102,211) 0:00:00.10
Framesize
132
*SpeedK
NOT_SET
*L2Timeout
0:00:08.25
Name
is the device name of the line.
Address
reports the Layer 2 primary and secondary addresses (system numbers).
Delay
specifies the time interval that a data bit spends on the line during message
transmission. See Time Values on page 15-6 for the time interval format. In this
case, Delay is 0.10 seconds. The line-handler process uses the transmission size,
the amount of delay before the message can be dispatched, and the DELAY
modifier value to select the most efficient line for data transmission within a path
that consists of multiple line logical devices. This value should match the expected
transmission delay across the communications facility.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier value to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Expand Configuration and Management Manual—523347-008
15 -29
Subsystem Control Facility (SCF) Commands
Direct-Connect and Satellite-Connect Line-Handler
Processes
SpeedK
calculates the time factor of the line for the Expand routing algorithm. A value of
NOT_SET means that this parameter was not set. See SPEEDK n on page 17-23
for a discussion of SPEEDK.
L2Timeout
reports the time interval of the Layer 2 T1 timer.
For direct-connect line-handler and satellite-connect line-handler processes, the
display for a LINE object with the DETAIL option has the format as shown in
Example 15-4. The asterisk (*) indicates an alterable attribute.
Example 15-4. INFO LINE, DETAIL Command, Direct- and Satellite-Connect LineHandler Processes
-> INFO LINE $SWNLBA1, DETAIL
EXPAND
Detailed Info
LINE
L2Protocol
SWAN_DIRECT
Framesize.......
132
*LinePriority....
1
*DownIfBadQuality
OFF
*TxWindow........
7
LineBufSize.....
47288
*Interface.......
RS232
DRtimeout..... 0:00:03.00
*L2Timeout..... 0:00:08.25
*ClockMode......
DCE
*CLBdwnloadTimr 0:00:30.00
*LineTf..........
0
$SWNLBA1
(LDEV
310)
TimeFactor......
inf *SpeedK........
NOT_SET
-Rsize...........
-Speed........
StartUp.........
OFF *Delay......... 0:00:00.10
*QualityThreshold
96 *QualityTimer.. 0:01:00.00
Address.......(102,211) *Autoload......
ON
*Dsrtimer.....0:00:01.00 *Idletimeout... 0:00:10.00
Readbuffers.....
8 *L2Retries.....
10
*CLBidleTimer 0:00:10.00 Threshold.....
500
Protocolid......
1 Flagfill......
ON
*ClockSpeed
19200 *CLBdwnloadRetries
3
*Program.........
$SYSTEM.CSS12.C1097P00
L2Protocol
lists the name of the Layer 2 protocol process associated with the Expand linehandler process.
TimeFactor
reports the current time factor for this line. See Routing and Time Factors on
page 18-22 for a discussion on time factors, including how to calculate them.
SpeedK
calculates the time factor of the line for the Expand routing algorithm. A value of
NOT_SET means that this parameter was not set. See SPEEDK n on page 17-23
for a discussion of SPEEDK.
Expand Configuration and Management Manual—523347-008
15 -30
Subsystem Control Facility (SCF) Commands
Direct-Connect and Satellite-Connect Line-Handler
Processes
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier value to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
Speed
calculates the time factor of the line for the Expand routing algorithm.
LinePriority
This can be set in the range 1 to 9. The default is 1. The higher the number, the
lower priority to use that line. If lines have equal priority, the relative line speeds
and transmission delays are used to select the next line.
StartUp
specifies that the line will be disabled (OFF) or enabled (ON) after a system load.
Delay
specifies the time interval, in one-hundredth of a second increments, that a data bit
spends on the line during message transmission. The line-handler process uses
the transmission size, the amount of delay before the message can be dispatched,
and the DELAY modifier value to select the most efficient line for data transmission
within a path that consists of multiple-line logical devices. This value should match
the expected transmission delay across the communications facility. In the
example above, it is 0.10 seconds.
DownIfBadQuality
This can be set either ON or OFF. The default is OFF. If set to ON and the
QualityTimer expires, an EMS message is generated and the line is aborted. If set
to OFF and the QualityTimer expires, an EMS message is generated and the line
is not aborted.
QualityThreshold
This can be set in the range 0 to 99. The default is 0. If the line reports quality
lower than this percentage value, a timer is started.
QualityTimer
This can be set in the range of 0 through 12 hours. The default is 0. Specifies the
time interval to wait after the line quality drops below the threshold value specified
Expand Configuration and Management Manual—523347-008
15 -31
Subsystem Control Facility (SCF) Commands
Direct-Connect and Satellite-Connect Line-Handler
Processes
in the QualityThreshold before taking the action specified in the parameter
DownIfBadQuality.
TxWindow
reports the number of Expand packets that the line-handler process can send
before receiving a reply.
Address
specifies the Layer 2 primary and secondary addresses. Addresses are system
numbers.
Autoload
reports whether or not the automatic downloading of microcode to the
communications line interface processor (CLIP) is enabled or disabled. In the
example above, it is enabled (ON). If AUTOLOAD is ON, the microcode is
downloaded to the CLIP whenever the CLIP restarts.
LineBufSize
reports the size of the Expand line buffer.
Dsrtimer
specifies the time interval, in one-hundredth of a second increments, that the
communications line interface processor (CLIP) will wait for the Data Set Ready
(DSR) signal from the modem before informing the Communications Access
Process (CAP) of no detection.
Idletimeout
reports the time interval to wait after modem loss before timing out.
Interface
reports the electrical interface (RS-232 or RS-449) used.
Readbuffers
shows the number of read frame buffers in the line buffer. Expand automatically
adjusts Readbuffers to be TXWINDOW + 4 for lines that use the SWAN
concentrator.
L2Retries
specifies the number of times that the line-handler process will retry a request at
Layer 2 before reporting an error.
Expand Configuration and Management Manual—523347-008
15 -32
Subsystem Control Facility (SCF) Commands
Direct-Connect and Satellite-Connect Line-Handler
Processes
DRtimeout
specifies the time interval that the line-handler process Communications Access
Process (CAP) will wait for a response to a request it has sent to the
communications line interface processor (CLIP).
CLBIdleTimer
specifies the time interval between communications line interface processor (CLIP)
status probes.
Threshold
specifies the number of information frames that must be sent and received before
line quality is calculated.
L2Timeout
specifies the length of time, in one-hundredth of a second increments, that the linehandler process will wait for a response to request at Layer 2 before retrying.
Protocolid
reports the communications line interface processor (CLIP) protocol identifier.
Flagfill
specifies whether a specific bit pattern called FLAG will be set during the idle
period for a line. A value of OFF causes the ServerNet wide area network (SWAN)
concentrator to keep an idle line in the MARK HOLD instead of the IDLE FLAGS
state. Some modems and data circuit-terminating equipment (DCE) require the idle
line state to be configured with FLAGFILL ON.
ClockMode
indicates whether the clocking signals for the communications line interface
processor (CLIP) clock are enabled (DTE) or disabled (DCE).
ClockSpeed
reports the clock rate (in bits per second) when ClockMode is DTE.
CLBdwnloadRetries
specifies the maximum number of times that the line-handler process will try to
download a communications line interface processor (CLIP).
CLBdwnloadTimr
specifies the time interval that the line-handler process will wait for successful
completion of a communications line interface processor (CLIP) download
operation.
Expand Configuration and Management Manual—523347-008
15 -33
Expand-Over-IP Line-Handler Processes
Subsystem Control Facility (SCF) Commands
Program
reports the file name of the communications line interface processor (CLIP)
program that will be downloaded.
LineTF
is the line time factor. LINETF has a range of 0 to 186, with a default of 0 (unset). If
you set LINETF, it overrides the RSIZE, SPEED, or SPEEDK parameters in
calculating the time factor for the line (PATHTF overrides all parameters, including
LINETF). If LINETF is left unset (a zero value), this parameter is not used in setting
the time factor.
Expand-Over-IP Line-Handler Processes
For Expand-over-IP line-handler processes, the display for a LINE object without the
DETAIL option has the format as shown in Example 15-5. The asterisk (*) indicates an
alterable attribute.
Example 15-5. INFO LINE Command, Expand-Over-IP Line-Handler Processes
-> INFO LINE $IPTAH0
Name
Delay
$IPTAH0
0:00:00.10
Framesize
132
*Associatedev
$ZTC02
*Maxreconnects
3
*Aftermaxretries
PASSIVE
Name
is the device name of the line.
Delay
is the expected line time required for a bit to arrive at the other end of the line. This
value is considered in multi-line paths to help packets arrive in the correct order at
the destination system.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier value to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Associatedev
reports the name of the NonStop TCP/IP, TCPSAM, or TCP6SAM process
associated with the Expand-over-IP line-handler process.
Maxreconnects
reports the maximum number of times the Expand-over-IP line-handler process will
try to connect to the remote system.
Expand Configuration and Management Manual—523347-008
15 -34
Expand-Over-IP Line-Handler Processes
Subsystem Control Facility (SCF) Commands
Aftermaxretries
is the line state once retries have been exhausted for the line. DOWN means the
line state will be down. PASSIVE means the Expand-over-IP process will issue
passive connect requests.
Example 15-6 shows the display format for a LINE object with the DETAIL option for
Expand-over-IP line-handler processes for IPv4 lines. The asterisk (*) indicates an
alterable attribute.
Example 15-6. INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler
Processes for IPv4 Lines
-> INFO LINE $IPTAH0, DETAIL
EXPAND
Detailed Info
LINE
L2Protocol
Net^Ip
Framesize.......
132
*LinePriority....
1
*DownIfBadQuality
OFF
*Txwindow........
7
*Timerreconnect 0:00:30.00
*Associatedev....
$ZTC02
*IPVer
IPV4
*DestIpAddr 16.107.189.66
*SrcIpAddr
16.107.188.54
*V6DestIpAddr
::
*V6SrcIpAddr
::
$IPTAH0
(LDEV
175)
TimeFactor......
-Rsize...........
StartUp.........
*QualityThreshold
*Maxreconnects...
*Retryprobe......
*LineTf..........
3
3
OFF
96
0
19
0
*DestIpPort......
*SrcIpPort.......
5744
5744
*SpeedK........
-Speed........
Delay.........
*QualityTimer..
*AfterMaxRetries
*Timerprobe....
*Timerinactivity
NOT_SET
0:00:00.10
0:01:00.00
PASSIVE
0:00:01.00
0:00:00.00
Example 15-7 shows the display format for a LINE object with the DETAIL option for
Expand-over-IP line-handler processes for IPv6 lines. The asterisk (*) indicates an
alterable attribute.
Note that the IPv6 display format is the same as the IPv4 display format. If the IPv6
addresses are not set, they are displayed as :: (two colons).
Expand Configuration and Management Manual—523347-008
15 -35
Expand-Over-IP Line-Handler Processes
Subsystem Control Facility (SCF) Commands
Example 15-7. INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler
Processes for IPv6 Lines
-> INFO LINE $IPTAH0, DETAIL
EXPAND
Detailed Info
LINE
$IPTAH0
(LDEV
175)
L2Protocol
Net^Ip TimeFactor......
3
Framesize.......
132 -Rsize...........
3
*LinePriority....
1 StartUp.........
OFF
*DownIfBadQuality
OFF *QualityThreshold
96
*Txwindow........
7 *Maxreconnects...
0
*Timerreconnect 0:00:30.00 *Retryprobe......
19
*Associatedev....
$ZTC02 *LineTf..........
0
*IPVer
IPV6
*DestIpAddr 16.107.190.66 *DestIpPort......11171
*SrcIpAddr
16.107.188.67 *SrcIpPort.......11171
*V6DestIpAddr
fe80::a00:8eff:fe00:897b
*V6SrcIpAddr
fe80::a00:8eff:fe00:897a
*SpeedK........
-Speed........
Delay.........
*QualityTimer..
*AfterMaxRetries
*Timerprobe....
*Timerinactivity
NOT_SET
0:00:00.10
0:01:00.00
PASSIVE
0:00:01.00
0:00:00.00
L2Protocol
is the Layer 2 protocol process associated with the Expand-over-IP line-handler
process.
TimeFactor
reports the current time factor for this line. See Routing and Time Factors on
page 18-22 for a discussion on time factors, including how to calculate them.
SpeedK
calculates the time factor of the line for the Expand routing algorithm. A value of
NOT_SET means that this parameter was not set. See SPEEDK n on page 17-23
for a discussion of SPEEDK.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
Speed
calculates the time factor of the line for the Expand routing algorithm.
Expand Configuration and Management Manual—523347-008
15 -36
Subsystem Control Facility (SCF) Commands
Expand-Over-IP Line-Handler Processes
LinePriority
This can be set in the range 1 to 9. The default is 1. The higher the number, the
lower priority to use that line. If lines have equal priority, the relative line speeds
and transmission delays are used to select the next line.
Startup
indicates whether the line will be enabled (ON) or disabled (OFF) after a system
load.
Delay
is the expected line time required for a bit to arrive at the other end of the line. This
value is considered in multi-line paths to help packets arrive at the destination
system in the correct order.
DownIfBadQuality
This can be set either ON or OFF. The default is OFF. If set to ON and the
QualityTimer expires, an EMS message is generated and the line is aborted. If set
to OFF and the QualityTimer expires, an EMS message is generated and the line
is not aborted.
QualityThreshold
This can be set in the range 0 to 99. The default is 0. If the line reports quality
lower than this percentage value, a timer is started.
QualityTimer
This can be set in the range of 0 through 12 hours. The default is 0. Specifies the
time interval to wait after the line quality drops below the threshold value specified
in the QualityThreshold before taking the action specified in the parameter
DownIfBadQuality.
Txwindow
is the number of Expand packets that the Expand-over-IP line-handler process can
send before receiving a reply.
Maxreconnects
is the maximum number of times the Expand-over-IP line-handler process will try
to connect to the remote system.
AfterMaxRetries
is the line state after all retries have been exhausted for the line.
Expand Configuration and Management Manual—523347-008
15 -37
Subsystem Control Facility (SCF) Commands
Expand-Over-IP Line-Handler Processes
Timerreconnect
is the time interval the Expand-over-IP line-handler process will wait for a
successful connection.
Retryprobe
is the number of times the Expand-over-IP line-handler process will retry the probe
of the remote Expand-over-IP line-handler process before concluding that the
network is unavailable.
Timerprobe
is the time interval that the Expand-over-IP line-handler process will wait to probe
the remote Expand-over-IP line-handler process.
Associatedev
reports the name of the NonStop TCP/IP, TCPSAM, or TCP6SAM process
associated with the Expand-over-IP line-handler process.
LineTF
is the line time factor. LINETF has a range of 0 to 186, with a default of 0 (unset). If
you set LINETF, it overrides the RSIZE, SPEED, or SPEEDK parameters in
calculating the time factor for the line (PATHTF overrides all parameters, including
LINETF). If LINETF is left unset (a zero value), this parameter is not used in setting
the time factor.
Timerinactivity
is the time interval the Expand-over-IP line-handler process will wait while the line
is inactive before it requests the disconnection of the network service. The default
value is 0 (no timer).
IPVer
specifies whether the destination and source addresses are IPv4 or IPv6. The
default is IPv4.
DestIpAddr
is the TCP/IP address used by the remote Expand-over-IP line-handler process. It
is used only if the IPVER is IPv4.
DestIpPort
is the port number used by the remote Expand-over-IP line-handler process. It is
used for both IPVER IPv4 and IPv6.
Expand Configuration and Management Manual—523347-008
15 -38
Subsystem Control Facility (SCF) Commands
Expand-Over-ATM Line-Handler Processes
SrcIpAddr
is the TCP/IP address used by the local Expand-over-IP line-handler process. It is
used only if the IPVER is IPv4.
SrcIpPort
is the port number used by the local Expand-over-IP line-handler process. It is
used for both IPVER IPv4 and IPv6.
V6DestIpAddr
is the destination NonStop TCP/IPv6 address used by the remote Expand-over-IP
line-handler process. It is used only if the IPVER is IPv6.
V6SrcIpAddr
is the source NonStop TCP/IPv6 address used by the local Expand-over-IP linehandler process. It is used only if the IPVER is IPv6.
Expand-Over-ATM Line-Handler Processes
For Expand-over-ATM line-handler processes, the display for a LINE object without the
DETAIL option has the format as shown in Example 15-8. The asterisk (*) indicates an
alterable attribute.
Example 15-8. INFO LINE Command, Expand-Over-ATM Line-Handler Processes
-> INFO LINE $AMLBA0
EXPAND
Name
$AMLBA0
Info
LINE
Delay
Framesize *Associatedev *Associatesubdev
0:00:00.10
132
$AM2
#IP
Name
is the device name of the line.
Delay
is the expected line time required for a bit to arrive at the other end of the line. This
value is considered in multi-line paths to help packets arrive at the destination
system in the correct order.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Expand Configuration and Management Manual—523347-008
15 -39
Expand-Over-ATM Line-Handler Processes
Subsystem Control Facility (SCF) Commands
Associatedev
reports the name of the ATM line associated with the Expand-over-ATM linehandler process.
Associatesubdev
reports the name of the ATM service access point (SAP). The only currently
supported ATM SAP is #IP.
Example 15-9 shows the display format for a LINE object with the DETAIL option for
Expand-over-ATM line-handler processes that use permanent virtual circuits (PVCs).
The asterisk (*) indicates an alterable attribute.
Example 15-9. INFO LINE, DETAIL Command, Expand-Over-ATM Line-Handler
Processes
-> INFO LINE $AMLBA0, DETAIL
EXPAND
Detailed Info
LINE
L2Protocol
Net^Atm
Framesize.......
132
*LinePriority....
1
*DownIfBadQuality
OFF
*Txwindow........
7
*Timerreconnect 0:00:30.00
*Associatedev....
$AM2
ConnEp....... %H2061CF10
*PvcName.........
PVC10
*LineTf..........
0
$AMLBA0
(LDEV
307)
TimeFactor......
1
-Rsize...........
StartUp.........
OFF
*QualityThreshold
96
*Maxreconnects...
0
*Retryprobe......
19
*Associatesubdev
#IP
ListenEp.... %H00000000
*SpeedK........
-Speed........
Delay.........
*QualityTimer..
*AfterMaxRetries
*Timerprobe....
*Timerinactivity
*CallType......
OC12
0:00:00.10
0:01:00.00
PASSIVE
0:00:01.00
0:00:00.00
PVC
L2Protocol
is the Layer 2 protocol process associated with the Expand-over-IP line-handler
process.
TimeFactor
reports the current configured or calculated time factor for this line. See Routing
and Time Factors on page 18-22 for a discussion about time factors, including how
to calculate them.
SpeedK
calculates the time factor of the line for the Expand routing algorithm. A value of
NOT_SET means that this parameter was not set. See SPEEDK n on page 17-23
for a discussion of SPEEDK.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier to
calculate the packet size and determine the size of the frame buffers. If the default
FRAMESIZE modifier value is used, the packet size is 132 words.
Expand Configuration and Management Manual—523347-008
15 -40
Subsystem Control Facility (SCF) Commands
Expand-Over-ATM Line-Handler Processes
Rsize
specifies the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
Speed
calculates the time factor of the line for the Expand routing algorithm.
LinePriority
This can be set in the range 1 to 9. The default is 1. The higher the number, the
lower priority to use that line. If lines have equal priority, the relative line speeds
and transmission delays are used to select the next line.
Startup
indicates whether the line will be enabled (ON) or disabled (OFF) after a system
load.
Delay
is the expected line time required for a bit to arrive at the other end of the line. This
value is considered in multi-line paths to help packets arrive at the destination
system in the correct order.
DownIfBadQuality
This can be set either ON or OFF. The default is OFF. If set to ON and the
QualityTimer expires, an EMS message is generated and the line is aborted. If set
to OFF and the QualityTimer expires, an EMS message is generated and the line
is not aborted.
QualityThreshold
This can be set in the range 0 to 99. The default is 0. If the line reports quality
lower than this percentage value, a timer is started.
QualityTimer
This can be set in the range of 0 through 12 hours. The default is 0. Specifies the
time interval to wait after the line quality drops below the threshold value specified
in the QualityThreshold before taking the action specified in the parameter
DownIfBadQuality.
Txwindow
is the number of Expand packets that the Expand-over-ATM line-handler process
can send before receiving a reply.
Expand Configuration and Management Manual—523347-008
15 -41
Subsystem Control Facility (SCF) Commands
Expand-Over-ATM Line-Handler Processes
Maxreconnects
is the maximum number of times the Expand-over-ATM line-handler process will try
to connect to the remote system.
AfterMaxRetries
is the line state after all retries have been exhausted for the line.
Timerreconnect
is the time interval the Expand-over-ATM line-handler process will wait for a
successful connection.
Retryprobe
is the number of times the Expand-over-ATM line-handler process will retry the
probe of the remote Expand-over-ATM line-handler process before concluding that
the network is unavailable.
Timerprobe
is the time interval that the Expand-over-ATM line-handler process will wait to
probe the remote Expand-over-ATM line-handler process.
Associatedev
reports the name of the ATM line associated with the Expand-over-ATM linehandler process.
Associatesubdev
reports the name of the ATM service access point (SAP). The only currently
supported ATM SAP is #IP.
Timerinactivity
is the time interval the Expand-over-ATM line-handler process will wait while the
line is inactive before it requests the disconnection of the network service. This
modifier does not apply to Expand-over-ATM lines.
ConnEp
is the connection endpoint control block address. (This field is for internal HP use
only.)
ListenEp
is the listen endpoint control block address. (This field is for internal HP use only.)
CallType
indicates whether a permanent virtual circuit (PVC), a switched virtual circuit
(SVC), or the SLSA ATMSAP connection option is used.
Expand Configuration and Management Manual—523347-008
15 -42
Subsystem Control Facility (SCF) Commands
Expand-Over-NAM, Expand-Over-ServerNet, and
Expand-Over-FOX Line-Handler Processes
PvcName
is the name of the permanent virtual circuit (PVC).
LineTF
is the line time factor. LINETF has a range of 0 to 186, with a default of 0 (unset). If
you set LINETF, it overrides the RSIZE, SPEED, or SPEEDK parameters in
calculating the time factor for the line (PATHTF overrides all parameters, including
LINETF). If LINETF is left unset (a zero value), this parameter is not used in setting
the time factor.
Expand-Over-NAM, Expand-Over-ServerNet, and Expand-OverFOX Line-Handler Processes
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, the display for a LINE object without the DETAIL option has the format as
shown in Example 15-10. The asterisk (*) indicates an alterable attribute.
Example 15-10. INFO LINE Command, Expand-Over-NAM, Expand-OverServerNet, and Expand-Over-FOX Line-Handler Processes
-> INFO LINE $FXKAU
EXPAND
Info LINE
Name
$FXKAU
Delay
0:00:00.10
Framesize *L2Timeout *Associatedev *Associatesubdev
132
0:00:01.00
$ZZFOX
Name
is the device name of the line.
Delay
specifies the time interval, in one-hundredth of a second increments, that a data bit
spends on the line during message transmission. The line-handler process uses
the transmission size, the amount of delay before the message can be dispatched,
and the DELAY modifier value to select the most efficient line for data transmission
within a path that consists of multiple line logical devices.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier value to
calculate the packet size. The FRAMESIZE modifier value also determines the size
of the frame buffers.
Expand Configuration and Management Manual—523347-008
15 -43
Subsystem Control Facility (SCF) Commands
Expand-Over-NAM, Expand-Over-ServerNet, and
Expand-Over-FOX Line-Handler Processes
L2Timeout
reports the time interval of the Layer 2 T1 timer.
Associatedev
reports the name of the X25AM or SNAX/APN process associated with the
Expand-over-NAM process. For Expand-over-ServerNet line-handler processes,
this field shows $ZZSCL, and for Expand-over-FOX line-handler processes, this
field shows $ZZFOX.
Associatesubdev
reports the name of the NAM subdevice that will be activated by the Expand-overNAM process. The subdevice name for Expand-over-X.25 line-handler processes
is the name of an X25AM subdevice. For Expand-over-SNA line-handler processes
it is the subdevice name of a SNAX/APN logical unit (LU). This field is not used by
Expand-over-ServerNet or Expand-over-FOX line-handler processes.
Example 15-11 shows the display format for a LINE object with the DETAIL option for
Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler
processes. The asterisk (*) indicates an alterable attribute.
Example 15-11. INFO LINE, DETAIL Command, Expand-Over-NAM, Expand-OverServerNet, and Expand-Over-FOX Line-Handler Processes
-> INFO LINE $FXKAU, DETAIL
EXPAND
Detailed Info
LINE
$FXKAU
(LDEV
135)
L2Protocol
Net^Nam TimeFactor......
1 *SpeedK........
NOT_SET
Framesize.......
132 -Rsize...........
1 -Speed........
*LinePriority....
1 StartUp.........
OFF Delay......... 0:00:00.10
Rxwindow........
7 *Timerbind... 0:01:00.00 *L2Timeout..... 0:00:01.00
*Txwindow........
7 *Maxreconnects...
0 *AfterMaxRetries
PASSIVE
*Timerreconnect 0:01:00.00 *Retryprobe......
10 *Timerprobe.... 0:00:30.00
*Associatedev....
$ZZFOX *Associatesubdev
*Timerinactivity 0:00:00.00
*ConnectType..... ACTIVEANDPASSIVE
*LineTf..........
0
L2Protocol
lists the name of the Layer 2 protocol process associated with the Expand-overNAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process.
TimeFactor
reports the current time factor for this line. See Routing and Time Factors on
page 18-22 for a discussion about time factors, including how to calculate them.
Expand Configuration and Management Manual—523347-008
15 -44
Subsystem Control Facility (SCF) Commands
Expand-Over-NAM, Expand-Over-ServerNet, and
Expand-Over-FOX Line-Handler Processes
SpeedK
calculates the time factor of the line for the Expand routing algorithm. A value of
NOT_SET means that this parameter was not set. See SPEEDK n on page 17-23
for a discussion of SPEEDK.
Framesize
specifies the maximum size frame that can be sent in the network; smaller frames
may be sent. The Expand subsystem also uses the FRAMESIZE modifier value to
calculate the packet size. The FRAMESIZE modifier value also determines the size
of the frame buffers.
Rsize
displays the time factor of the line for the Expand routing algorithm. RSIZE can be
0 if the time factor is set using some other modifier.
Speed
calculates the time factor of the line for the Expand routing algorithm.
LinePriority
can be set in the range 1 to 9. The default is 1. The higher the number, the lower
priority to use that line. If lines have equal priority, the relative line speeds and
transmission delays are used to select the next line.
StartUp
shows that the line will be disabled (OFF) or enabled (ON) after a system load.
Delay
reports the time interval between transmissions. See Time Values on page 15-6 for
a description of the time interval format.
Rxwindow
specifies the number of packets that the input-output process (IOP) will send to the
line-handler process before the line-handler process must send a reply.
Timerbind
specifies the time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait for a completion of its bind request
to the NAM process. See Time Values on page 15-6 for a description of the time
interval format
Expand Configuration and Management Manual—523347-008
15 -45
Subsystem Control Facility (SCF) Commands
Expand-Over-NAM, Expand-Over-ServerNet, and
Expand-Over-FOX Line-Handler Processes
L2Timeout
specifies the time interval that the line-handler process will wait for a response to
request at Layer 2 before retrying. See Time Values on page 15-6 for a description
of the time interval format
Txwindow
reports the number of Expand packets that the line-handler process can send
before receiving a reply.
Maxreconnects
is the maximum number of times the Expand-over-NAM, Expand-over-ServerNet,
or Expand-over-FOX line-handler process will try a connect request after
successfully binding to the NAM interface.
AfterMaxRetries
lists the line state once all retries have been exhausted for the Expand-over-NAM,
Expand-over-ServerNet, or Expand-over-FOX line-handler process. DOWN causes
the line state to be down. PASSIVE causes the Expand-over-NAM process to
switch to PASSIVECONNECTONLY (which supersedes the function of
ACTIVEANDPASSIVECONNECT). This attribute applies to Expand-over-NAM,
Expand-over-ServerNet, and Expand-over-FOX line-handler processes that have
the MAXRECONNECTS modifier set to a nonzero value.
Timerreconnect
specifies the time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait for a connection request to
succeed. See Time Values on page 15-6 for a description of the time interval
format
Retryprobe
reports the number of times that the Expand-over-NAM, Expand-over-ServerNet,
or Expand-over-FOX line-handler process will retry its probe of the NAM before
deciding that the network is unavailable.
Timerprobe
specifies the time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait to obtain the status of the NAM
process. See Time Values on page 15-6 for a description of the time interval format
Associatedev
reports the name of the X25AM or SNAX/APN process associated with the
Expand-over-NAM process. For Expand-over-ServerNet line-handler processes,
this field shows $ZZSCL, and for Expand-over-FOX line-handler processes, this
field shows $ZZFOX.
Expand Configuration and Management Manual—523347-008
15 -46
Subsystem Control Facility (SCF) Commands
Considerations
Associatesubdev
reports the name of the NAM subdevice that will be activated by the Expand-overNAM process. The subdevice name for Expand-over-X.25 line-handler processes
is the name of an X25AM subdevice. For Expand-over-SNA line-handler
processes, it is the name of a SNAX/APN logical unit (LU). This field is not used by
Expand-over-ServerNet or Expand-over-FOX line-handler processes.
Timerinactivity
specifies the time interval that an Expand-over NAM (i.e., Expand-over-X.25 or
Expand-over-SNA) line-handler process will wait during a period of inactivity before
requesting disconnection from the network service provided by the NAM process.
See Time Values on page 15-6 for a description of the time interval format.
Timerinactivity does not apply to Expand-over-ServerNet or Expand-over-FOX linehandler processes.
Connecttype
lists the Layer 2 Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX
line-handler process connect type. ACTIVEANDPASSIVE causes the network
access method (NAM) to first issue a call request and, if unsuccessful, wait for an
incoming call request. PASSIVE causes the NAM to wait for incoming call
requests; it will not initiate connect requests.
LineTF
is the line time factor. LINETF has a range of 0 to 186, with a default of 0 (unset). If
you set LINETF, it overrides the RSIZE, SPEED, or SPEEDK parameters in
calculating the time factor for the line (PATHTF overrides all parameters, including
LINETF). If LINETF is left unset (a zero value), this parameter is not used in setting
the time factor.
Considerations
You can display information about several lines with a single INFO command by
specifying multiple LINE objects using parentheses as follows:
LINE ( line-name , line-name [ , line-name ] ... )
INFO PROCESS Command
The INFO PROCESS command causes the display of selected information for the
network control process ($NCP). The information displayed can be the current attribute
settings for the local $NCP, the status of a selected path and the status of the started
lines that make up that path, or the status of the network as viewed from a selected
system.
The SUB and SEL options are not supported.
Expand Configuration and Management Manual—523347-008
15 -47
Subsystem Control Facility (SCF) Commands
INFO PROCESS Command
The INFO PROCESS command has the following syntax:
INFO [ /OUT file-spec / ] PROCESS $NCP
[ , { CONNECTS | LINESET | NETMAP | PATHSET | SUPERPATH |
SYSTEMS | RPT system-name } ]
[ , AT { system-list | * } ]
[ , TO { system-list | * } ]
[ , DETAIL ]
/OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
CONNECTS
displays the systems that are connected or connecting, and only the entry for
which the connection is established. If the path is a superpath, the CONNECTS
option displays all of the paths in the superpath.
LINESET
displays the status of a selected path and the status of the started lines that make
up that path.
Note. The LINESET option only displays information on active lines (lines that have been
started at least once after a system load). To see information on all configured lines, use the
SCF command LISTDEV TYPE 63.
NETMAP
displays the status of the network as seen from a specific system.
PATHSET
displays the NCP pathmap information, similar to the LINESET option but in a
different format. This new format displays both the line-handler LDEV and name,
as well as the other information already in the LINESET option.
SUPERPATH
displays the paths comprising each multi-CPU path on the system.
RPT system-name
displays the reverse pairing table (RPT) for the specified multi-CPU path.
Expand Configuration and Management Manual—523347-008
15 -48
Subsystem Control Facility (SCF) Commands
INFO PROCESS Command
SYSTEMS
displays all known systems. If no connection is established, the SYSTEMS option
displays an infinite time factor and hop count. The SYSTEMS option is similar to
the CONNECTS option, except that the CONNECTS option displays only the
systems connected.
Note. If none of the formatting options (LINESET, NETMAP, PATHSET, SUPERPATH, and
RPT) are specified, local $NCP information is displayed.
AT { system-list | * }
where
system-list
is ( [ sys-a [ , sys-b [ , sys-c [ , .... ] ] ] ] ).
sys-a
is {\system-name | system-number }.
sys-b
is {\system-name | system-number }.
sys-c
is {\system-name | system-number }.
If the NETMAP, SUPERPATH, or RPT option is chosen, only one system can be
specified.
If the SUPERPATH option is chosen, the display lists the multi-CPU paths on a
remote node.
If the RPT option is chosen, the display lists the reverse pairing table (RPT) on a
remote node.
If the AT option is omitted, the SCF target system is assumed.
If AT * is specified and the LINESET or PATHSET option is chosen, the display is
the status of a selected path and the lines that make up the path of all accessible
nodes in the network.
TO { system-list | * }
where
system-list
is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).
Expand Configuration and Management Manual—523347-008
15 -49
INFO PROCESS Command
Subsystem Control Facility (SCF) Commands
sys-a
is {\system-name | system-number }.
sys-b
is {\system-name | system-number }.
sys-c
is {\system-name | system-number }.
The TO option is valid only when NETMAP has been selected. It causes the
display of the network status as viewed from the system specified in the AT option
through the system specified in the TO option.
If the TO option is omitted and the NETMAP option is selected, the status of the
whole network as seen from the system specified in the AT option is displayed. If
this option is specified as TO * and the NETMAP option is selected, the status of
the whole network as seen from the system specified in the AT option is displayed.
DETAIL
causes detailed information of $NCP attributes to be displayed. If not specified,
only one line of $NCP attribute information is displayed.
The display for the INFO PROCESS $NCP command without the DETAIL option has
the format as shown in Example 15-12. The asterisk (*) denotes an alterable attribute.
Example 15-12. INFO PROCESS $NCP Command
-> INFO PROCESS $NCP
EXPAND Info PROCESS $NCP AT \NODEA (151)
Name
$NCP
AutomaticMaptimer
ON
Framesize
#132
*Maxtimeouts
3
*Maxconnects
5
Name
is the device name of the network control process ($NCP).
AutomaticMaptimer
reports the current map-propagation rate in effect in the Expand network.
Framesize
reports the network-wide frame size (in words) used by all line-handler processes
in the Expand network. $NCP uses this value to calculate the number of entries in
the distance vector (DV) or map packet (that is, the maximum size of the map
packet).
Expand Configuration and Management Manual—523347-008
15 -50
INFO PROCESS Command
Subsystem Control Facility (SCF) Commands
Maxtimeouts
defines the maximum number of retry attempts allowed to establish a connection.
Maxconnects
specifies the maximum number of times $NCP will attempt a connection (CONN)
request.
The display for the INFO PROCESS $NCP command with the DETAIL option has the
format as shown in Example 15-13. The asterisk (*) denotes an alterable attribute.
Example 15-13. INFO PROCESS $NCP, DETAIL Command
-> INFO PROCESS $NCP, DETAIL
EXPAND
Detailed Info PROCESS
Max System Number..
Algorithm..........
*Connecttime........
*Maxtimeouts........
*NetworkDiameter....
*Message 43.........
Message 45.........
Message 47.........
*Message 49.........
Next Rebalance Time
Trace File Name....
$NCP
AT \NODEA
(117)
254 *Aborttimer.........
MODIFIEDSPLIT
AutomaticMaptimer..
0:00:00.00
Framesize..........
3 *Maxconnects........
15
Type...............
OFF
Message 44.........
ON *Message 46.........
ON *Message 48.........
OFF *AutoRebal..........
0/00:00:00 *AutoRebalTime......
\NODEA.$SYSTEM.SYSTEM.NCPLOG
0:00:40.00
ON
132
5
(62,0)
ON
OFF
OFF
OFF
1/00:00:00
Max System Number
reports the highest valid system number allowed within the network.
Aborttimer
specifies the length of time $NCP will wait before aborting requests destined for a
remote system to which an alternate path has not yet been identified.
ABORTTIMER must be set to the same value on all systems in the network.
Algorithm
identifies the $NCP routing algorithm to be used. In this case, it is modified split
horizon (MSH).
AutomaticMaptimer
specifies a distance vector (DV) propagation rate of 8 seconds multiplied by the
time factor (TF) for the path (ON), or an algorithm with a 5-minute propagation
interval (OFF).
Expand Configuration and Management Manual—523347-008
15 -51
Subsystem Control Facility (SCF) Commands
INFO PROCESS Command
Connecttime
specifies the amount of time, in seconds, that $NCP will wait for a response to its
connection request. If 0 is shown, $NCP computes the connection request timer
independently for each connection using the following formula:.
5 seconds * tf_to_destination, where tf_to_destination is the time factor to the
destination system.
Framesize
is used by $NCP to compute the maximum size, in words, of a distance vector
(DV) packet.
Note. The network control process FRAMESIZE modifier and the Layer 2 SCF FRAMESIZE
modifier have the same name. Both the network control process and the Layer 2 FRAMESIZE
modifiers are configured using the SCF interface to the WAN subsystem. Expand modifiers are
described in Section 17, Expand Modifiers
Maxtimeouts
defines the maximum number of retry attempts allowed to establish a connection.
Maxconnects
specifies the maximum number of times $NCP will attempt a connection (CONN)
request.
NetworkDiameter
specifies the maximum number of intervening systems (hops) in a path between
two systems.
Type
reports the device type (device-type,subtype). $NCP is 62,0.
Message 43
reports whether the reporting of event message 43 to $0 is enabled (ON) or
disabled (OFF). Message 43 is a critical message. It means that the connection to
the indicated system has been lost.
Message 44
reports whether the reporting of event message 44 to $0 is enabled (ON).
Message 44 is not critical. It means that the indicated line is now ready to accept
network requests.
Message 45
reports whether the reporting of event message 45 to $0 is enabled (ON).
Message 45 is a critical message. It means that the indicated line is no longer
ready.
Expand Configuration and Management Manual—523347-008
15 -52
Subsystem Control Facility (SCF) Commands
INFO PROCESS Command
Message 46
reports whether the reporting of event message 46 to $0 is enabled (ON) or
disabled (OFF). Message 46 is not critical. It means a connection has been made
with the indicated remote system.
Message 47
reports whether the reporting of event message 47 to $0 is enabled (ON).
Message 47 is a critical message. It means that an end-to-end acknowledgment
was not received from the indicated system within the configured Layer 4 timeout
interval.
Message 48
reports whether the reporting of event message 48 to $0 is enabled (ON) or
disabled (OFF). Message 48 is a critical message. It means that a change in
processor status has occurred at the indicated system.
Message 49
reports whether the reporting of event message 49 to $0 is enabled (ON) or
disabled (OFF). Message 49 is a critical message. It means that $NCP has not
received a status message from $NCP at the indicated system for three time
periods.
AutoRebal
reports whether automatic rebalancing of the multi-CPU paths on the system is
enabled (ON) or disabled (OFF).
Next Rebalance Time
shows the time of day of the next scheduled automatic rebalancing of multi-CPU
paths on the system. The time of day is displayed in the following format:
[DDD/]HH:MM:SS
where
[DDD/]
shows the number of days that the specified time of day will be skipped before
the next automatic rebalancing will occur.
HH
shows the hours.
MM
shows the minutes.
Expand Configuration and Management Manual—523347-008
15 -53
CONNECTS Option
Subsystem Control Facility (SCF) Commands
SS
shows the seconds.
AutoRebalTime
reports the time interval for automatic rebalancing of the multi-CPU paths on the
system. Rebalancing will occur periodically at the time interval shown. The time
interval is displayed in the format described for the Next Rebalance Time
attribute.
Trace File Name
the name of the trace file specified in the SCF TRACE command.
CONNECTS Option
The INFO PROCESS $NCP CONNECTS option displays the systems that are
connected or connecting, and only the entry for which the connection is established. If
the path is a multi-CPU path (superpath), the CONNECTS option displays all of the
paths in the multi-CPU path. It is basically a summary of the NETMAP command, but
shows only the connected entries.
Example 15-14. INFO PROCESS $NCP Command, CONNECTS Option
-> INFO PROCESS $NCP, CONNECTS
EXPAND
Info
PROCESS
$NCP, CONNECTS
CONNECTS AT \NODEA (117) #LINESETS=7 TIME:
System
82 \NODEB
Time(Dist)
1(01)
123 \NODEC
160 \NODED
254 \NODEE
4(02)
4(02)
7(03)
Lset:LHname
1:$SPATH1
3:$SPATH2
3:$SPATH2
5:$IPTAH1
1:$SPATH1
(Ldev)
( 122)&
( 121)*
( 121)*
( 125)+
( 122)*
FEB 24,2003 13:55:29
Lset:LHname (Ldev)
2:$SPATH0 ( 123)&
System
indicates the number and the name of the system, or node.
Time(Dist)
these entries show the time factor (TIME) and number of hops (DISTANCE) for
each path between systems in the network and the selected system. A value of inf
(--) (for infinite) indicates that there is no connection to the selected system. Each
row and column entry represents a path connecting the selected system to the
system listed in the leftmost column. (Refer to Routing and Time Factors on
page 18-22 for more information on the TF.) An asterisk (*) indicates the Expand
line-handler process selected for traffic to each known node in the network; this is
Expand Configuration and Management Manual—523347-008
15 -54
Subsystem Control Facility (SCF) Commands
LINESET Option
also the line-handler process used for the $NCP connection protocol with each
node.
For multi-CPU paths, the asterisk has a different meaning for non-neighbor nodes
than for neighbor nodes. For non-neighbor nodes, the asterisk indicates the
Expand line-handler process selected for the pair between the local node and each
remote node; all traffic to the remote node uses the indicated line-handler process.
For neighbor nodes, traffic can also be directed to any of the other Expand linehandler processes in the multi-CPU path; an asterisk in this case indicates the linehandler process used for the $NCP connection protocol and an ampersand (&) is
shown beside the other members of the multi-CPU path.
Lset:LHname
Lset (lineset) indicates the path number, or lineset number. LHname is the name of
the line handler involved.
Ldev
indicates the logical device (LDEV) number associated with each line logical
device. After the LDEV number, an asterisk (*), or plus (+), or ampersand (&)
symbol indicates the following:
* indicates that the line is connected
+ indicates that the line is in the process of connecting
& indicates that the LDEV is a multi-CPU path
LINESET Option
The information displayed for the INFO PROCESS $NCP command with the LINESET
option is taken from $NCP’s path table. It is a subset of the information shown by the
NETMAP command. They both have an AT option to show information from the
viewpoint of another system.
$NCP updates its path table when it receives a READY or NOT READY message from
an Expand line-handler process. If an Expand line-handler process is not started after
a system load, then the line does not appear in $NCP’s path table and thus does not
appear in the display for the INFO PROCESS $NCP command with the LINESET
option.
Note. If a pre-G06.12 system that can support only 63 linehandlers runs the command, INFO
PROCESS $NCP, LINESET, AT \NEW to send the LINESET request to a system that can
display 255 linehandlers, the number of entries in the reply is limited to 63, the number of
entries that the pre-G06.12 system can display.
The display for the INFO PROCESS $NCP command with the LINESET option has the
format as shown in Example 15-15:
Expand Configuration and Management Manual—523347-008
15 -55
LINESET Option
Subsystem Control Facility (SCF) Commands
Example 15-15. INFO PROCESS $NCP Command, LINESET Option
-> INFO PROCESS $NCP, LINESET
EXPAND
Info
PROCESS
LINESETS AT \NODEA
LINESET
NEIGHBOR
1 S
\NODEB
(082)
$NCP
(117) #LINESETS=7 TIME:
LDEV
122
2 S
\NODEB
(082)
123
3 S
\NODEB
(082)
121
4
\NODEB
(082)
131
5
\NODEB
(082)
125
6
\NODEF
(247)
132
7
\NODEF
(247)
175
AT \nnn
, LINESET
TF
PID
LINE
1 ( 1, 334)
1
1 ( 0, 333)
1
1 ( 0, 332)
1
-- -- ----1
3 ( 2, 271)
1
-- -- ----1
-- -- ----1
2
3
4
FEB 24,2003 13:55:04
LDEV
STATUS
122
READY
123
READY
121
READY
FileErr#
131 NOT READY (066)
125
READY
132 NOT READY (066)
212
254
256
259
NOT
NOT
NOT
NOT
READY
READY
READY
READY
(066)
(066)
(066)
(066)
(xxx)
is the name (nnn) and number (xxx) of the system selected.
#LINESETS=nn
is the number of paths (nn) connected through this system.
LINESET n
these entries describe each communications path (LINESET) directly connected to
the selected system. If the path is a multi-line path, the logical device (LDEV)
number associated with each line logical device is also displayed. An “S” next to a
LINESET indicates that it is a member of a multi-CPU path.
NEIGHBOR
indicates the neighbor node that data is transmitted to over the path.
LDEV
indicates the logical device (LDEV) number associated with each line logical
device.
Expand Configuration and Management Manual—523347-008
15 -56
Subsystem Control Facility (SCF) Commands
LINESET Option
TF
indicates time factors in this display. To use old time-factor values, use the
command INFO PROCESS $NCP, OLDLINESET.
If you are using the OLDLINESET option on a G06.20 node, the command INFO
PROCESS $NCP, LINESET, AT \remote, where \remote is a G06.19 node,
displays super time factor information, and the command INFO PROCESS $NCP,
OLDLINESET, AT \remote displays non-super time factor information.
PID
is the process ID.
LINE
indicates the device name of a line.
LDEV
indicates the logical device (LDEV) number associated with each line logical
device.
STATUS
indicates the status of the line: ready or not ready.
Note. If a line handler becomes hung for more than 60 seconds such that the NCP cannot
communicate with it, the LINESET option shows “NOT READY (201)” in the STATUS field.
If this occurs, you must abort and restart the line handler to put the path back into use. The
linehandler has been observed to only get into this situation during extremely heavy FOX
pass-through traffic.
FileErr#
shows the most recent file system error number, if any, associated with each line.
Expand Configuration and Management Manual—523347-008
15 -57
NETMAP Option
Subsystem Control Facility (SCF) Commands
NETMAP Option
The display for the INFO PROCESS $NCP command with the NETMAP option has the
format as shown in Example 15-16:
Example 15-16. INFO PROCESS $NCP Command, NETMAP Option
-> INFO PROC $NCP,NETMAP
EXPAND
Info
PROCESS
$NCP, NETMAP
NETMAP AT \NODEA (117) #LINESETS=7 TIME:
FEB 24,2003 13:54:46
SYSTEM
82 \NODEB
TIME
1(01)&
inf(--)
(DISTANCE) BY
1(01)&
1(01)*
PATH
inf(--)
3(01)
inf(--)
123 \NODEC
4(02)
inf(--)
4(02)
inf(--)
6(02)
inf(--)
[
[
6]
7]
151 \NODEG
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
[
[
6]
7]
160 \NODED
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)+
inf(--)
[
[
6]
7]
247 \NODEF
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
[
[
6]
7]
254 \NODEE
7(03)*
inf(--)
7(03)
7(03)
inf(--)
9(03)
inf(--)
[
[
6]
7]
4(02)*
INDEX
[ 6]
[ 7]
--------------------------------------------------------------LINESETS AT \NODEA
LINESET
NEIGHBOR
1 S
\NODEB
(082)
LDEV
122
2 S
\NODEB
(082)
123
3 S
\NODEB
(082)
121
4
\NODEB
(082)
131
5
\NODEB
(082)
125
6
\NODEF
(247)
132
7
\NODEF
(247)
175
(117) #LINESETS=7
TF
PID
LINE
1 ( 1, 334)
1
1 ( 0, 333)
1
1 ( 0, 332)
1
-- -- ----1
3 ( 2, 271)
1
-- -- ----1
-- -- ----1
2
3
4
LDEV
STATUS
122
READY
123
READY
121
READY
FileErr#
131 NOT READY (066)
125
READY
132 NOT READY (066)
212
254
256
259
NOT
NOT
NOT
NOT
READY
READY
READY
READY
(066)
(066)
(066)
(066)
AT \nnn (xxx)
is the name (nnn) and number (xxx) of the system from which the network is
viewed.
Expand Configuration and Management Manual—523347-008
15 -58
Subsystem Control Facility (SCF) Commands
NETMAP Option
#LINESETS=n
indicates that there are n communications paths (LINESETS) directly connected to
the selected system. The LINESETS are listed in detail after the NETMAP table.
The systems in the network are listed by the system number followed by the
system name.
SYSTEM
indicates the number and the name of the system, or node.
TIME (DISTANCE) BY PATH
these entries show the time factor (TIME) and number of hops (DISTANCE) for
each path between systems in the network and the selected system. A value of
inf (--) (for infinite) indicates that there is no connection to the selected system.
Each row and column entry represents a path connecting the selected system to
the system listed in the leftmost column. (Refer to Routing and Time Factors on
page 18-22 for more information on the TF.) An asterisk (*) indicates the Expand
line-handler process selected for traffic to each known node in the network; this is
also the line-handler process used for the $NCP connection protocol with each
node.
For multi-CPU paths, the asterisk has a different meaning for non-neighbor nodes
than for neighbor nodes. For non-neighbor nodes, the asterisk indicates the
Expand line-handler process selected for the pair between the local node and each
remote node; all traffic to the remote node uses the indicated line-handler process.
For neighbor nodes, traffic can also be directed to any of the other Expand linehandler processes in the multi-CPU path; an asterisk in this case indicates the linehandler process used for the $NCP connection protocol and an ampersand (&) is
shown beside the other members of the multi-CPU path.
INDEX
indicates the associated LINESET number for the entry in the particular row. The
index number is used to identify the LINESET associated with any NETMAP entry.
LINESET n
these entries describe each communications path (LINESET) directly connected to
the selected system. If the path is a multi-line path, the logical device (LDEV)
number associated with each line logical device is also displayed. An “S” next to a
LINESET indicates that it is a member of a multi-CPU path.
NEIGHBOR
indicates the neighbor node that data is transmitted to over the path.
LDEV
indicates the logical device (LDEV) number associated with each line logical
device.
Expand Configuration and Management Manual—523347-008
15 -59
Subsystem Control Facility (SCF) Commands
NETMAP Option
TF
indicates time factors in this display.
If you are using the OLDNETMAP option on a G06.20 node, the command INFO
PROCESS $NCP, LINESET, AT \remote, where \remote is a G06.19 node,
displays super time factor information, and the command INFO PROCESS $NCP,
OLDLINESET, AT \remote displays non-super time factor information.
PID
is the process ID.
LINE
indicates the device name of a line.
LDEV
indicates the logical device (LDEV) number associated with each line logical
device.
STATUS
indicates the status of the line: ready or not ready.
FileErr#
is the last file-system error returned for the path. For recovery information on file
errors, refer to Identifying Network Problems on page 21-3.
Expand Configuration and Management Manual—523347-008
15 -60
PATHSET Option
Subsystem Control Facility (SCF) Commands
PATHSET Option
The PATHSET option displays the NCP pathmap information, similar to the LINESET
option but in a different format. This format displays both the line-handler LDEV and
name, as well as the other information already in the LINESET option.
Example 15-17. INFO PROCESS $NCP Command, PATHSET Option
-> INFO PROCESS $NCP, PATHSET
EXPAND Info PROCESS
$NCP
PATHSETS AT \NODEA
Ls Neighbor(node)
1 S \NODEB (082)
2 S \NODEB
(082)
3 S \NODEB
(082)
4
\NODEB
(082)
5
\NODEB
(082)
6
\NODEF
(247)
7
\NODEF
(247)
,PATHSETS
(117) #LINESETS=7 TIME:
TF (Cpu,Pin) Line Name
1 ( 1, 334)
$SPATH1
1
$SPATH1
1 ( 0, 333)
$SPATH0
1
$SPATH0
1 ( 0, 332)
$SPATH2
1
$SPATH2
----- (--,-----)
$IPSTAH
1
$IPSTAH
3 ( 2, 271)
$IPTAH1
1
$IPTAH1
----- (--,-----)
$IPSFIJ
1
$IPSFIJ
----- (--,-----)
$IPFIJP
1
$IPFIJ02
2
$IPFIJ03
3
$IPFIJ00
4
$IPFIJ01
FEB 24,2003 13:55:18
(LDEV)
( 122)
( 122)
( 123)
( 123)
( 121)
( 121)
( 131)
( 131)
( 125)
( 125)
( 132)
( 132)
( 175)
( 212)
( 254)
( 256)
( 259)
Status
FileErr#
READY
READY
READY
NOT READY
(066)
READY
NOT READY
(066)
NOT
NOT
NOT
NOT
(066)
(066)
(066)
(066)
READY
READY
READY
READY
Ls
indicates each communications path (LINESET) directly connected to the selected
system. If the path is a multi-line path, the logical device (LDEV) number
associated with each line logical device is also displayed. An “S” next to a
LINESET indicates that it is a member of a multi-CPU path.
Neighbor(node)
indicates the neighbor node that data is transmitted to over the path.
TF
reports the current time factor for this line. See Routing and Time Factors on
page 18-22 for a discussion on time factors, including how to calculate them.
Cpu, Pin
uniquely identifies a process. This number consists of the processor number and
the process identification number (PIN).
Line
indicates the line number.
Expand Configuration and Management Manual—523347-008
15 -61
RPT Option
Subsystem Control Facility (SCF) Commands
Name
indicates the device name of the line.
Ldev
indicates the logical device (LDEV) number associated with each line logical
device.
Status
indicates the status of the line; whether it is ready or not ready.
FileErr
shows the most recent file system error number, if any, associated with each line.
For recovery information on file errors, refer to Identifying Network Problems on
page 21-3.
RPT Option
The display for the INFO PROCESS $NCP command with the RPT option has the
format as shown in Example 15-18:
Example 15-18. INFO PROCESS $NCP Command, RPT Option
-> INFO PROCESS $NCP, RPT \NODEA
EXPAND
Info
PROCESS
$NCP
, RPT
SUPERPATHS AT \NODEB (85) #SUPERPATHS=1
S-PATH
1
NEIGHBOR
\NODEA
(102)
SYS/LDEV
80 234
SYS/LDEV
190 245
TIME: APR 26,2000 13:55:01
SYS/LDEV
SYS/LDEV
AT \nnn (xxx)
is the name (nnn) and number (xxx) of the system at which the reverse pairing
table (RPT) is viewed.
SPATH n
these entries describe information kept in the RPT for each multi-CPU path
(SPATH) on the selected system. When data is transmitted to a non-neighbor node
over a multi-CPU path, the RPT is used to direct traffic from the remote node to the
Expand line-handler process from which a connection initiation was received. The
source system numbers and the logical devices (LDEVs) to which traffic from the
source system should be directed are shown in the SYS/LDEV columns. Only
entries with valid LDEVs are displayed. For more information about the RPT, refer
to Network Routing Table (NRT) and Multiple Path Table (MPT) on page 18-25.
Expand Configuration and Management Manual—523347-008
15 -62
SUPERPATH Option
Subsystem Control Facility (SCF) Commands
NEIGHBOR
indicates the neighbor node that data is transmitted to over the path.
SYS/LDEV
indicates the number and the name of the system, or node, and the logical device
(LDEV) number.
SUPERPATH Option
The display for the INFO PROCESS $NCP command with the SUPERPATH option
has the format as shown in Example 15-19:
Example 15-19. INFO PROCESS $NCP Command, SUPERPATH Option
-> INFO PROCESS $NCP, SUPERPATH
EXPAND
Info
PROCESS
SUPERPATHS AT \NODEA
S-PATH
1
NEIGHBOR
\NODEB
(082)
$NCP
, SUPERPATH
(117) #SUPERPATHS=1
LDEV
122
121
123
TF
1
1
1
LF
1.00
1.00
1.00
TIME: FEB 24,2003 13:55:48
LCPU
1
0
0
RCPU
1
2
0
AT \nnn (xxx)
is the name (nnn) and number (xxx) of the system from which the multi-CPU
paths are viewed.
SPATH n
these entries describe each multi-CPU path (SPATH) on the selected system. The
effective time factor (ETF) is an extension of the path time factor (TF) that is used
to select a path in a multi-CPU path. The ETF represents not only the speed of the
path, but also the resources available on the path to accommodate more traffic.
The LCPU and RCPU fields report the local processor and remote processor
numbers. For more information about the ETF, refer to Best-Path Route Selection
on page 18-24.
NEIGHBOR
indicates the neighbor node that data is transmitted to over the path.
LDEV
indicates the logical device (LDEV) number associated with each line logical
device.
TF
indicates super time factors in this display.
Expand Configuration and Management Manual—523347-008
15 -63
SYSTEMS Option
Subsystem Control Facility (SCF) Commands
LF
indicates the load factor for the path in a multi-CPU path (superpath). The effective
time factor (ETF) is calculated based on the load factor (ETF = LF * TF).
LCPU
indicates the local processor number.
RCPU
indicates the remote processor number.
Superpath Rebalancing Considerations
A Superpath rebalance can introduce a temporary disruption in the network, similar to
but, in general, less than that caused by an Expand path change. For that reason, it is
recommended that rebalances be limited to off-peak hours unless an imbalance is
clearly causing immediate problems.
SYSTEMS Option
The SYSTEMS option displays all known systems. If no connection is established, the
SYSTEMS option displays an infinite time factor and hop count. The SYSTEMS option
is similar to the CONNECTS option, except that the CONNECTS option displays only
the systems connected.
Example 15-20. INFO PROCESS $NCP Command, SYSTEMS Option
-> INFO PROCESS $NCP, SYSTEMS
EXPAND
Info
PROCESS
$NCP, SYSTEMS
SYSTEMS AT \NODEA (117) #LINESETS=7 TIME:
System
82 \NODEB
123
151
160
247
254
Time(Dist)
1(01)
\NODEC
\NODEG
\NODED
\NODEF
\NODEE
4(02)
inf(--)
32767(--)
inf(--)
7(03)
Lset:LHname
1:$SPATH1
3:$SPATH2
3:$SPATH2
(Ldev)
( 122)&
( 121)*
( 121)*
FEB 24,2003 13:55:37
Lset:LHname (Ldev)
2:$SPATH0 ( 123)&
5:$IPTAH1 ( 125)+
1:$SPATH1 ( 122)*
System
indicates the number and the name of the system, or node.
Time(Dist)
These entries show the time factor (TIME) and number of hops (DISTANCE) for
each path between systems in the network and the selected system. A value of inf
(--) (for infinite) indicates that there is no connection to the selected system. Each
row and column entry represents a path connecting the selected system to the
Expand Configuration and Management Manual—523347-008
15 -64
Subsystem Control Facility (SCF) Commands
PRIMARY PROCESS Command
system listed in the leftmost column. (Refer to Routing and Time Factors on
page 18-22 for more information on the TF.) An asterisk (*) indicates the Expand
line-handler process selected for traffic to each known node in the network; this is
also the line-handler process used for the $NCP connection protocol with each
node.
For multi-CPU paths, the asterisk has a different meaning for non-neighbor nodes
than for neighbor nodes. For non-neighbor nodes, the asterisk indicates the
Expand line-handler process selected for the pair between the local node and each
remote node; all traffic to the remote node uses the indicated line-handler process.
For neighbor nodes, traffic can also be directed to any of the other Expand linehandler processes in the multi-CPU path; an asterisk in this case indicates the linehandler process used for the $NCP connection protocol and an ampersand (&) is
shown beside the other members of the multi-CPU path.
Lset:LHname
Lset (lineset) displays the status of a selected path and the status of the started
lines that make up that path. LHname is the name of the line handler involved.
Ldev
indicates the logical device (LDEV) number associated with each line logical
device. After the LDEV number, an asterisk (*), or plus (+), or ampersand (&)
symbol indicates the following:
* indicates that the line is connected
+ indicates that the line is in the process of connecting
& indicates that the LDEV is a multi-CPU path
PRIMARY PROCESS Command
The PRIMARY PROCESS command causes the backup process to become the
primary process and the primary to become the backup. PRIMARY PROCESS is a
sensitive command.
The PRIMARY PROCESS command has the following syntax:
PRIMARY PROCESS { line-name | path-name | $NCP } , cpu-number
line-name | path-name
is the name of the line or path to be switched to the backup processor.
$NCP
causes the backup processor to become the primary processor and the primary to
become the backup for $NCP.
Expand Configuration and Management Manual—523347-008
15 -65
Subsystem Control Facility (SCF) Commands
Considerations
cpu-number
is the processor number that will now become the primary processor for the
specified line or path.
Considerations
•
•
•
•
•
If the specified processor is not either the backup or primary processor, an error is
returned.
If the specified processor is currently the primary processor, a warning is returned.
The PRIMARY PROCESS command is not supported directly for Expand-over-IP
or Expand-over-PTCPIP line-handler processes. However, if you want to switch an
Expand-over-TCPIP or an Expand-over-PTCPIP line to the backup CPU, you can
abort the line handler, use the PRIMARY PROCESS command, and then restart
the line in the backup CPU.
The PRIMARY PROCESS command is used after an ABORT PATH command to
switch to the backup $NCP and reinitialize the node. See Node Not Available on
page 21-35.
You can switch processors for objects with a single PRIMARY PROCESS
command by specifying multiple objects using parentheses as follows:
PROCESS ( object-name , object-name [ , object-name ] ... )
Examples
The following SCF command causes the backup processor (CPU 6) to become the
primary processor and the primary to become the backup for $LINEX:
-> PRIMARY PROCESS $LINEX, 6
The following SCF command causes the backup processor (CPU 1) to become the
primary processor and the primary to become the backup for $NCP:
-> PRIMARY PROCESS $NCP, 1
The following SCF command causes the backup processor (CPU 0) to become the
primary processor and the primary to become the backup for $LHCOM and $LHBAL:
-> PRIMARY PROCESS ($LHCOM, $LHBAL), 0
Expand Configuration and Management Manual—523347-008
15 -66
Subsystem Control Facility (SCF) Commands
PROBE PROCESS Command
PROBE PROCESS Command
The PROBE PROCESS command applies only to $NCP. PROBE displays the current
paths to one or more, or all, of the remote systems within a network, from a specified
system within the network. PROBE PROCESS is a nonsensitive command.
The PROBE PROCESS command has the following syntax:
PROBE [ / OUT file-spec / ] PROCESS $NCP
[ , AT { \system-name | system-number } ]
[ , TO { system-list | * } ]
/ OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
AT { \system-name | system-number }
is a specific system name or system number from which the probe is made. If this
option is omitted, the SCF target system name is assumed and the probe is made
from the SCF target system. Entering the SYSTEM \system-name | systemnumber command prior to issuing the PROBE command is equivalent to the AT
attribute.
TO { system-list | * }
where
system-list is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).
sys-a
is { \system-name | system-number }.
sys-b
is { \system-name | system-number }.
sys-c
is { \system-name | system-number }.
system-list identifies the system, or systems, to which the probe is made.
*
denotes all accessible systems in the network. That is, the probe is made to all
accessible systems. If the TO parameter is omitted, * is assumed and the
probe is made to all accessible systems in the network.
Expand Configuration and Management Manual—523347-008
15 -67
PROBE PROCESS Command
Subsystem Control Facility (SCF) Commands
Assume that you have entered the following commands:
-> SYSTEM \NODEA
-> PROBE PROCESS $NCP, TO (\NODEB, \NODEC, \NODED, &
-> \NODER, \NODEQ)
The display resulting from these commands has the format as shown in
Example 15-21:
Example 15-21. PROBE PROCESS $NCP Command
>PROBE PROCESS $NCP, AT \NODEA, TO (\NODEB,\NODEC,\NODEW,\NODER,\NODEQ)
NETPROBES AT \NODEA
(003)
Time: MAR 11,2000 11:20:37
2 \NODEB - * (00002 ms)
4 \NODEC - \NODER - \NODED - \NODEW - \NODEB - * (00003 ms)
5 \NODED - \NODEW - \NODEH - \NODEB - * (00002 ms)
6 \NODER - \NODED - \NODEW - \NODEH - \NODEB - *
(00003 ms)
7 \NODEQ - * (00003 ms)
NETPROBES AT \NODEA
(003)
indicates the system name and system number from which the probe was made.
2 \NODEB - *
(00002 ms)
indicates that the probe was made from the system named \NODEA to the system
named \NODEB. The list begins with \NODEB and ends at the system from which
the probe was made, indicated by the asterisk *. The connection is direct—there is
no system in between. The value in parentheses (00002 ms) indicates that the
round-trip time for this probe was 2 milliseconds.
4 \NODEC - \NODER - \NODED - \NODEW - \NODEB - *
(00003 ms)
indicates that the probe was made from \NODEA to \NODEC. The list begins with
\NODEC and ends at the system from which the probe was made, indicated by the
asterisk *. The systems in between are \NODER, \NODED, \NODEW, and
\NODEB. The value in parentheses (00003 ms) indicates that the round-trip time
for this probe was 3 milliseconds.
5 \NODED - \NODEW - \NODEH - \NODEB - *
(00002 ms)
indicates that the probe was made from \NODEA to \NODED. The list begins with
\NODED and ends at the system from which the probe was made, indicated by the
asterisk *. The systems in between are \NODEW, \NODEH, and \NODEB. The
value in parentheses (00002 ms) indicates that the round-trip time for this probe
was 2 milliseconds.
6 \NODER - \NODED - \NODEW - \NODEH - \NODEB - *
(00003 ms)
indicates that the probe was made from \NODEA to \NODER. The list begins with
\NODER and ends at the system from which the probe was made, indicated by the
asterisk *. The systems in between are \NODED, \NODEW, \NODEH, and
Expand Configuration and Management Manual—523347-008
15 -68
Subsystem Control Facility (SCF) Commands
START Command
\NODEB. The value in parentheses (00003 ms) indicates that the round-trip time
for this probe was 3 milliseconds.
7 \NODEQ - *
(00003 ms)
indicates that the probe was made from \NODEA to \NODEQ. The list begins with
\NODEQ and ends at the system from which the probe was made, indicated by the
asterisk *. The connection is direct; there is no system in between. The value in
parentheses (00003 ms) indicates that the round-trip time for this probe was
3 milliseconds.
Note. The preceding display shows that only two systems, \NODEB and \NODEQ, are
connected directly to the local system (\NODEA). This display also shows that all systems
except \NODEQ are connected to the local system (\NODEA) through \NODEB.
START Command
The START command initiates the operation of a line or path. The successful
completion of the START command leaves the line or path in the STARTED state.
START is a sensitive command.
The START command has the following syntax:
START { PATH path-name | LINE line-name }
line-name | path-name
is the name of the line or path to be started.
Considerations
•
•
•
•
•
If PATH is the object type, all lines associated with the path are started.
If LINE is the object type, the line is started.
If the communications line interface processor (CLIP) is in the boot state, the CLIP
firmware is downloaded.
The nonerror completion of the START command indicates only that the
subsystem was able to initiate processing for the START operation. It does not
indicate that the START operation completed successfully.
You can start several lines or paths with a single START command by specifying
multiple LINE or PATH objects using parentheses as follows:
-> LINE ( line-name , line-name [ , line-name ] ... )
-> PATH ( path-name , path-name [ , path-name ] ... )
Expand Configuration and Management Manual—523347-008
15 -69
Subsystem Control Facility (SCF) Commands
Examples
Examples
The following SCF command starts a line named $LHCMP2:
-> START LINE $LHCMP2
The following SCF command starts a path named $PTS and all lines associated with it:
-> START PATH $PTS
The following SCF commands starts lines named $LHCMP3 and $LHCMP4:
-> START LINE ($LHCMP3,$LHCMP4)
STATS Command
The STATS command displays statistical information about Expand paths and lines
and $NCP. STATS without the RESET option is a nonsensitive command; STATS with
the RESET option is a sensitive command.
Notes. Analyzing these statistics requires a thorough understanding of the Expand subsystem.
Refer to Section 18, Subsystem Description, for an explanation of the packet types listed
below.
If you are collecting STATS on a regular basis, be sure to reset them on a regular basis also,
so that they will not overflow and display invalid values.
STATS PATH Command
The STATS PATH command has the following syntax:
STATS [ / OUT file-spec / ] PATH path-name
[ , TO { nnn | \node_name } ]
[ , RESET ]
/ OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
path-name
is the name of the path.
nnn
is the decimal node number.
node-name
is the name of the node, such as \NODEA.
Expand Configuration and Management Manual—523347-008
15 -70
STATS PATH Command
Subsystem Control Facility (SCF) Commands
RESET
resets the statistical counters for the specified path. This is a sensitive command.
The display for a PATH object has the format as shown in Example 15-22:
Example 15-22. STATS PATH Command
-> STATS PATH $IPTAH1
EXPAND
Stats PATH
$IPTAH1,
PPID ( 2,
Reset Time.... FEB 10,2003 14:49:57
Current Ext Mem KBytes Used
Number of Known Systems
Ext Mem Allocation Fails
Current QIO KBytes Used
Current QIO MDs Used
------------------------<=
64 ..
0
<= 512 ..
0
<= 4096 ..
0
384
1
0
0
0
293), BPID ( 3,
304)
Sample Time.. FEB 11,2003 16:41:46
Max Ext Mem KBytes Used
Number of OOS Timeouts
QIO Allocation Fails
Max QIO KBytes Used
Max QIO MDs Used
384
0
0
0
1
LEVEL 4 MESSAGE HISTOGRAM -----------------------<= 128 ..
0
<= 256..
0
<= 1024 ..
0
<= 2048..
0
<= 32K ..
0
> 32K ..
0
-------------------------- LEVEL 4 DETAIL --------------------------------SENT: LRQ
LCMP
CANCEL
ACK
NAK
ENQ
PING
0
0
0
0
0
0
0
RCVD: LRQ
LCMP
CANCEL
ACK
NAK
ENQ
PING
0
0
0
0
0
0
0
L4 Packets Discarded
0
LCMP Mismatch Errors
0
Cur OOS in K Bytes
0
Max OOS Used in K Bytes
0
-------------------------- LEVEL 3 DETAIL --------------------------------SENT: PKTS
FORWARDS
LINKS
CONN
TRACE
NCPM
PCHG
131
0
0
1
0
128
2
RCVD: PKTS
FORWARDS
LINKS
CONN
TRACE
NCPM
PCHG
131
1
0
0
0
128
2
Sent:
Av Packets/Frame
1.0
Av Bytes/Frame
223
Rcvd:
Av Packets/Frame
1.0
Av Bytes/Frame
223
Bad Dest Pin Rcvd
0
Bad Src Pin Rcvd
0
Bad Checksum Rcvd
0
Looping Packets
0
Pckt Too Small/Large
0
Misc Bad Packets
0
------------------------ QUEUE
Security Requests
L3 Transfer
L3 Waiting LDONE
L5 Waiting EXT/Shared Memory
L4 Waiting Shared Memory
------------------------ LEVEL
Xmit Timeouts
ReXmit Packets
DEPTHS
-----------------------CURRENT
0
MAXIMUM
9
CURRENT
0
MAXIMUM
0
CURRENT
0
MAXIMUM
1
CURRENT
0
MAXIMUM
0
CURRENT
0
MAXIMUM
0
4 / CONGESTION CONTROL ---------------------0
ReXmit Timeouts
0
0
ReIdle Timeouts
0
PPID
is the primary process ID.
BPID
is the backup process ID.
Expand Configuration and Management Manual—523347-008
15 -71
Subsystem Control Facility (SCF) Commands
STATS PATH Command
Reset Time
is the last time the statistics counters were reinitialized.
Sample Time
is the time of the current statistics display.
Current Ext Mem KBytes Used
is the current amount of extended memory used, in KBytes.
Max Ext Mem KBytes Used
is the maximum amount, in KBytes, of extended memory used since the last
statistics reset or line-handler process start.
Number of Known Systems
is the total number of nodes known to this path.
Number of OOS Timeouts
is the total number of out-of-sequence (OOS) timeouts since statistics were last
reset using the STATS RESET command or since the line-handler process was
started. OOS timeouts occur when the OOS timer expires before the next packet in
the sequence arrives. If your system experiences a large number of OOS timeouts,
you might want to increase the OSTIMEOUT value by using the ALTER Command
described earlier in this section.
Ext Mem Allocation Fails
is the number of extended memory allocation failures since statistics were last
reset using the STATS RESET command or since the line-handler process was
started.
QIO Allocation Fails
is the number of QIO memory allocation failures since statistics were last reset
using the STATS RESET command or since the line-handler process was started.
Current QIO KBytes Used
is the current total number of kilobytes of QIO memory space, including overhead
and control data, being used to support messages over the specified path.
Max QIO KBytes Used
is the maximum total number of kilobytes of QIO memory space since the last
statistics reset or line-handler process start, including overhead and control data,
that was used at any one instant to support messages over the specified path.
Expand Configuration and Management Manual—523347-008
15 -72
Subsystem Control Facility (SCF) Commands
STATS PATH Command
Current QIO MDs Used
indicates the current QIO message descriptors used. A message descriptor is an
internal structure used for sending and receiving messages to and from QIO.
Max QIO MDs Used
indicates the maximum QIO message descriptors used since the last statistics
reset or line-handler process start. A message descriptor is an internal structure
used for sending and receiving messages to and from QIO.
LEVEL 4 MESSAGE HISTOGRAM
is the overall count of messages sent and received by this node over this path,
classified by size in bytes since statistics were last reset using the STATS RESET
command, or since the line-handler process was started. The counts do not include
any passthrough traffic. Note that not every request is completed, because a
CANCEL request might have been issued.
LEVEL 4 DETAIL
is the total number of packets sent and received, broken down by message type,
since statistics were last reset using the STATS RESET command, or since the
line-handler process was started. Sent relates to packets originating from this
node. Rcvd refers to packets destined for this node.
The Expand message types reported are as follows:
LRQ
LCMP
CANCEL
ACK
NAK
ENQ
PING
LINK request
LINK completion message
CANCEL request
ACKNOWLEDGMENT
Negative ACKNOWLEDGMENT
ENQUIRY request
PING requests and replies
Note. Since PING requests and PING replies only occur in pairs, only the sum of PING
requests and PING replies is shown. The Expand message types are defined and
described in Message Handling and Buffer Allocation on page 18-38.
L4 Packets Discarded
is the number of incoming Level 4 packets discarded because they were
duplicates or received too far out of sequence.
LCMP Mismatch Errors
is the number of incoming message completions discarded because they could
not be matched with a message link request.
Expand Configuration and Management Manual—523347-008
15 -73
Subsystem Control Facility (SCF) Commands
STATS PATH Command
Cur OOS in K Bytes
is the amount of memory, in kilobytes, currently being used to store packets
received out of sequence on this path.
Max OOS Used in K Bytes
is the maximum amount of memory, in kilobytes, that has been used to store
packets received out of sequence on this path.
LEVEL 3 DETAIL
is the total number of packets sent and received, broken down by message type,
since statistics were last reset using the STATS RESET command, or since the
line-handler process was started. Sent relates to packets originating from this
node. Rcvd refers to packets destined for this node.
The Expand message types reported are as follows:
PKTS
FORWARDS
LINKS
CONN
TRACE
NCPM
PCHG
Packets
Packets forwarded
Links
CONNECT request
TRACE/PROBE request
$NCP-to-$NCP message
PATHCHANGE message
Av Packets/Frame
returns the average number of packets in each block of data if the value of
PathBlockBytes is greater than 0.
Av Bytes/Frame
returns the average number of bytes received or sent in each block of data.
Bad Dest Pin Rcvd
is the number of incoming packets discarded because they contained an
invalid destination ID.
Bad Src Pin Rcvd
is the number of incoming packets discarded because they contained an
invalid source ID.
Bad Checksum Rcvd
is the number of incoming packets discarded because they contained an
invalid checksum value.
Expand Configuration and Management Manual—523347-008
15 -74
Subsystem Control Facility (SCF) Commands
STATS PATH Command
Looping Packets
is the number of incoming packets discarded because they contained the same
source ID as the receiver. This can happen if the underlying transport medium
is looping back packets or if there is a system with a duplicate node number in
the network.
Pckt Too Small/Large
is the number of incoming packets discarded because they contained either
less or more data than expected when the packet was read into the local
buffers.
Misc Bad Packets
is the number of packets received that were discarded for other reasons than
bad source pin, bad dest pin, bad checksum, looping, or out of sequence.
QUEUE DEPTHS CURRENT / MAXIMUM
displays the current queue depths and the maximum queue depths since the last
reset or line-handler process start, for the following queues.
Security Requests
is the current or maximum number of secure requests queued for security
checking.
L3 Transfer
is the current or maximum number of level 3 packets queued for transfer.
L3 Waiting LDONE
is the current or maximum number of level 3 requests awaiting an LDONE
reply from the remote.
L5 Waiting EXT/Shared Memory
is the current or maximum number of level 5 requests awaiting extended or
shared memory.
L4 Waiting Shared Memory
is the current or maximum number of level 4 requests awaiting shared memory.
LEVEL 4 / CONGESTION CONTROL
displays the congestion control statistics for the specified path.
Xmit Timeouts
is the number of transmission timeouts.
Expand Configuration and Management Manual—523347-008
15 -75
Subsystem Control Facility (SCF) Commands
Considerations
ReXmit Timeouts
is the number of retransmission timeouts.
ReXmit Packets
is the number of retransmitted packets.
ReIdle Timeouts
is the number of idle timeouts causing the congestion window to be reduced.
Considerations
You can display statistics for several paths with a single STATS PATH command by
specifying multiple PATH objects using parentheses as follows:
PATH ( path-name , path-name [ , path-name ] ... )
Examples
The following SCF command displays statistical information for a path named $PATH1:
-> STATS PATH $PATH1
The following SCF command displays statistical information for two paths names
$PATH2 and $PATH3:
-> STATS PATH ($PATH2,$PATH3)
STATS PATH NODE Command
The STATS PATH NODE command has the following syntax:
STATS [ / OUT file-spec / ] PATH path-name
[ , TO { nnn | \node-name } ]
[ , RESET ]
/ OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
path-name
is the name of the path.
TO nnn
is the destination system, where nnn is the decimal node number.
Expand Configuration and Management Manual—523347-008
15 -76
STATS PATH NODE Command
Subsystem Control Facility (SCF) Commands
node-name
is the destination node name, such as \NODEA.
RESET
resets the statistical counters for the PATH to NODE. This is a sensitive command.
The display for a NODE object has the format as shown in Example 15-23:
Example 15-23. STATS PATH NODE Command
SCF > STATS PATH $SC082,TO \NODEA
EXPAND
Stats PATH $SC082, PPID ( 2,
299), BPID ( 3,
292)
STATS TO NODE \NODEA (82)
Reset Time.... AUG 27,2002 14:47:34
Sample Time.. AUG 27,2002 15:50:52
---------------------------- MESSAGE HISTOGRAM -------------------------<=
64 ..
23166
<= 128 ..
13120
<= 256..
57
<= 512 ..
8636
<= 1024 ..
1351
<= 2048..
6
<= 4096 ..
0
<= 32K ..
0
>
32K..
706
---------------------------- PACKET STATISTICS -------------------------Control
Data
Links
LRQs
LCMPs
Sent
715
23176
10679
10679
12497
Rcvd
23182
12497
12503
10679
0
Sent
Rcvd
Cancel
0
706
Ack
706
0
Nak
0
0
Enq
0
0
Ping
0
0
LCMP Mismatches
0
Packets Discarded
0
------------------------- CONGESTION CONTROL STATISTICS ----------------Xmit Timeouts
0
ReXmit Timeouts
0
Rexmit Packets
0
ReIdle Timeouts
30
Current CWND
0
Max CWND
0
-------------------------------- QUEUE DEPTHS --------------------------Pending Pend Cancel
Transfer
Ack
Wait
CUR
0
0
0
0
0
MAX
0
0
1
1
0
Active
0
1
CUR
MAX
Oos
0
12497
PPID
is the primary process ID.
BPID
is the backup process ID.
Reset Time
is the last time the statistics counters were reinitialized.
Expand Configuration and Management Manual—523347-008
15 -77
Subsystem Control Facility (SCF) Commands
STATS PATH NODE Command
Sample Time
is the time of the current statistics display.
MESSAGE HISTOGRAM
is the overall count of messages sent and received by this node over this path,
classified by size in bytes since statistics were last reset using the STATS RESET
command, or since the line-handler process was started. The counts do not include
any passthrough traffic. Note that not every request is completed, because a
CANCEL request might have been issued.
PACKET STATISTICS
is the total number of packets sent and received, broken down by message type,
since statistics were last reset since the line-handler process was started. Sent
relates to packets originating from this node. Rcvd refers to packets destined for
this node.
Packet statistics are reported as follows:
Control
Data
Links
LRQs
LCMPs
Cancel
Ack
Nak
Enq
Ping
Control packets
Data packets
Links
Link requests
Link completion messages
Cancel request
Acknowledgment
Negative Acknowledgment
Enquiry request
PING requests and replies
LCMP Mismatches
is the number of incoming message completions discarded because they could
not be matched with a message link request.
Packets Discarded
is the number of incoming Level 4 packets discarded because they were
duplicates or were received too far out-of-sequence.
CONGESTION CONTROL STATISTICS
displays the congestion control statistics for the specified path.
Xmit Timeouts
is the number of transmission timeouts.
ReXmit Timeouts
is the number of retransmission timeouts.
Expand Configuration and Management Manual—523347-008
15 -78
Subsystem Control Facility (SCF) Commands
STATS PATH NODE Command
ReXmit Packets
is the number of retransmitted packets.
ReIdle Timeouts
is the number of idle timeouts causing the congestion window to be reduced.
Current CWND
displays the current congestion control window (CWND) value.
Max CWND
displays the maximum congestion control window (CWND) value attained.
QUEUE DEPTHS
displays the queue depth statistics for the specified path.
Pending
displays the number of pending requests queued.
Pend Cancel
displays the number of queued cancels.
Transfer
displays the number of queued transfers.
Ack
displays the number of queued messages awaiting acknowledgment from the
remote node.
Wait
displays the number of queued messages sent and acknowledged, awaiting
replies from the remote node.
Active
displays the number of messages received from the remote node and linked to
the local processes.
Oos
displays the number of out-of-sequence packets.
Expand Configuration and Management Manual—523347-008
15 -79
Examples
Subsystem Control Facility (SCF) Commands
Examples
The following SCF command displays statistical information for a path named $PATH1:
-> STATS PATH NODE1, TO NODE2
STATS LINE Command
The STATS LINE command has the following syntax:
STATS [ / OUT file-spec / ] LINE line-name
[ , RESET ]
/ OUT file-spec /
causes any SCF output generated by the command to be directed to the specified
file.
RESET
resets the statistical counters for the specified line. STATS LINE is a sensitive
command.
Expand-Over-IP Line-Handler Processes
For Expand-over-IP line-handler processes, the display for a LINE object has the
format as shown in Example 15-24:
Example 15-24. STATS LINE Command, Expand-Over-IP Line-Handler Processes
-> STATS LINE $LNFIJ
EXPAND
Stats LINE $LNFIJ, PPID ( 2,
69), BPID ( 3,
69)
Resettime... MAR 07,1997 16:06:48
Sampletime... JUN 13,2000 16:33:44
Sent
Rcvd
Conn Cmd
0
0
Conn Resp
0
0
Invalid Frames Rcvd
Frames Dropped
Mem Low
0
0
0
Data
0
0
Query Cmd
0
0
Invalid IP Addr Rcvd
Tx Window Available
Line Quality
PPID
is the primary process ID.
BPID
is the backup process ID.
Expand Configuration and Management Manual—523347-008
15 -80
Query Resp
0
0
0
10
100
Subsystem Control Facility (SCF) Commands
Expand-Over-IP Line-Handler Processes
Resettime
is the last time the statistics counters were reinitialized.
Sampletime
is the last time the statistics were collected.
Conn Cmd
is the command used to initiate a connect with a remote system. A connect
command is similar to the HDLC SABM frame.
Conn Resp
is the response to a connect command. This command completes the lowest level
of Expand-over-IP connection establishment.
Data
is the number of data frames sent and received.
Query Cmd
is the command used to probe the system for “I’m alive” status. A query command
is similar to the HDLC RR frame.
Query Resp
is the response to the query command that indicates that the remote system is up
and running.
Invalid Frames Rcvd
indicates that the frame received was too small (not big enough for frame
headers).
Invalid IP Addr Rcvd
indicates that the frame received was from an unexpected system. Check SRC
and destination addresses if this value increases and the line is not connecting.
This indicates a problem with configuration.
Frames Dropped
indicates the number of frames that have been dropped.
Tx Window Available
indicates the number of outstanding messages waiting for a reply.
Expand Configuration and Management Manual—523347-008
15 -81
Expand-Over-ATM Line-Handler Processes
Subsystem Control Facility (SCF) Commands
Mem Low
is the number of times a memory low indication was given to the Expand-over-IP
line-handler process from QIO. If the number is increasing, then the QIO resources
are running low.
Line Quality
is the line-quality value computed every 500 frames. This value is not alterable.
Line quality is computed using the following formula:
100 * (( TOTAL FRAMES - ERROR FRAMES ) / TOTAL FRAMES)
Line Quality reports a value below 100 only when the result of the formula is
95 or less; that is, when less than 95 percent of the packets are error-free.
Low line quality generally indicates a Layer 2 problem. Refer to Section 21,
Troubleshooting, for Layer 2 troubleshooting information.
Expand-Over-ATM Line-Handler Processes
For Expand-over-ATM line-handler processes, the display for a LINE object has the
format as shown in Example 15-25:
Example 15-25. STATS LINE Command, Expand-Over-ATM Line-Handler
Processes
-> STATS LINE $LNFIJ
EXPAND
Stats LINE $LNFIJ, PPID ( 2,
69), BPID ( 3,
69)
Resettime... JUN 14,2000 16:06:48
Sampletime... JUN 14,2000 16:33:44
Sent
Rcvd
Conn Cmd
0
0
Conn Resp
0
0
Invalid Frames Rcvd
Frames Dropped
Mem Low
0
0
0
Data
0
0
Query Cmd
0
0
Invalid ATM Addr Rcvd
Tx Window Available
Line Quality
PPID
is the primary process ID.
BPID
is the backup process ID.
Resettime
is the last time the statistics counters were reinitialized.
Sampletime
is the last time the statistics were collected.
Expand Configuration and Management Manual—523347-008
15 -82
Query Resp
0
0
0
0
100
Subsystem Control Facility (SCF) Commands
Expand-Over-ATM Line-Handler Processes
Conn Cmd
is the command used to initiate a connect with a remote system. A connect
command is similar to the HDLC SABM frame.
Conn Resp
is the response to a connect command. This command completes the lowest level
of Expand-over-ATM connection establishment.
Data
is the number of data frames sent and received.
Query Cmd
is the command used to probe the system for “I’m alive” status. A query command
is similar to the HDLC RR frame.
Query Resp
is the response to the query command that indicates that the remote system is up
and running.
Invalid Frames Rcvd
indicates that the frame received was too small (not big enough for frame
headers).
Invalid ATM Addr Rcvd
indicates that the frame received was from an unexpected system. Check SRC
and destination addresses if this value increases and the line is not connecting.
This indicates a problem with configuration.
Frames Dropped
indicates the number of frames that have been dropped.
Tx Window Available
indicates the number of outstanding messages waiting for a reply.
Mem Low
is the number of times a memory low indication was given to the Expand-over-ATM
line-handler process from QIO. If the number is increasing, then the QIO resources
are running low.
Expand Configuration and Management Manual—523347-008
15 -83
Expand-Over-ServerNet, Expand-Over FOX,
Expand-Over-X.25, and Expand-Over-SNA Line-
Subsystem Control Facility (SCF) Commands
Line Quality
is the line-quality value computed every 500 frames. This value is not alterable.
Line quality is computed using the following formula:
100 * (( TOTAL FRAMES - ERROR FRAMES ) / TOTAL FRAMES)
Line Quality reports a value below 100 only when the result of the formula is
95 or less; that is, when less than 95 percent of the packets are error-free.
Low line quality generally indicates a Layer 2 problem. Refer to Section 21,
Troubleshooting, for Layer 2 troubleshooting information.
Expand-Over-ServerNet, Expand-Over FOX, Expand-Over-X.25,
and Expand-Over-SNA Line-Handler Processes
For Expand-over-ServerNet, Expand-Over FOX, Expand-Over-X.25, and
Expand-Over-SNA line-handler processes, the display for a LINE object has the
format as shown in Example 15-26.
Example 15-26. STATS LINE Command, Expand-Over-ServerNet Line-Handler
Processes
-> STATS LINE $SNSLQ3
EXPAND
Stats LINE $SNSLQ3, PPID ( 2,
29), BPID ( 3,
58)
Resettime... JUN 09,2000 12:15:33
Sampletime... JUN 09,2000 12:48:11
MsgSent
RepRecv
MsgTout
ErrRecv
LastErr
Bind
4
4
0
0
0
Aconn
4
4
0
0
0
MsgSent
RepRecv
MsgTout
ErrRecv
LastErr
Unbind
4
4
0
0
0
Data
1399463
1399460
0
1
160
Proc lookup failures
0
Pconn
0
0
0
0
0
Query
32
32
0
0
0
Disc
0
0
0
0
0
MsgRecv
RepSent
ErrSent
LastErr
Notif
0
0
0
0
Data
1364604
1364604
0
0
Inactivity timeouts
0
PPID
is the primary process ID.
BPID
is the backup process ID.
Resettime
is the last time the statistics counters were reinitialized.
Expand Configuration and Management Manual—523347-008
15 -84
Subsystem Control Facility (SCF) Commands
Expand-Over-ServerNet, Expand-Over FOX,
Expand-Over-X.25, and Expand-Over-SNA Line-
Sampletime
is the last time the statistics were collected.
Bind
indicates the line handler bind to an associate device (such as $ZZFOX, $ZZSCL,
or $X25AM).
Aconn
indicates the number of connects while in active mode.
Pconn
indicates the number of connects while in passive mode. An active connect
message is expected as the reply.
Query
indicates that the Expand line-handler process is connected to the remote
(destination) Expand line-handler process, but no data has been received within
the inactivity interval (SCF TIMERPROBE attribute). The Expand line-handler
process is sending Probe messages to the remote Expand line-handler process to
verify that it is operational.
Queries test the connection to the associate device and do not go all the way
through to the remote line handler.
Disc
indicates the number of disconnect packets from the network service provided by
the network access method (NAM) process. Used for X25 and SNAX, disconnect
packets are sent to AssociateDev when the line is going inactive. You can set X.25
and SNAX lines to go inactive after a specified period with no in/out traffic. The line
remains up, but the underlying protocol is disconnected (this saves money on the
line).
Unbind
indicates the number of line-handler unbinds from an associate device (such as
$ZZFOX, $ZZSCL, or $X25AM). The line handler unbinds with the associate
device when it aborts.
Data
indicates the number of data frames sent. Normal FOX and ServerNet traffic are
not counted here because normal data traffic by-passes the line handler for these
processes.
Expand Configuration and Management Manual—523347-008
15 -85
SWAN Concentrator Lines
Subsystem Control Facility (SCF) Commands
Notif
indicates the notification message (NAM protocol). The Expand line handler does
not originate the notification message, but needs to receive it. The associate
device notifies the linehandler of any process changes on the remote system or the
connection (such as if the phandle changes).
Data
indicates the number of data frames received. Normal FOX and ServerNet traffic
are not counted here because normal data traffic by-passes the line handler for
these processes.
Proc lookup failures
process lookup failures indicate the number of failures to see the associate device.
Inactivity timeouts
indicates how many timeouts there were due to inactivity. Used for Expand-overX25 and Expand-over-SNAX.
SWAN Concentrator Lines
For Expand line-handler processes using ServerNet wide area network (SWAN)
concentrators, the display for a LINE object has the format shown in Example 15-27:
Example 15-27. STATS LINE Command, SWAN Concentrator Lines
-> STATS LINE $SWNLCW1
EXPAND
Stats LINE
$SWNLCW1, PPID ( 2,
Resettime... JUN 12,2000 09:29:43
20), BPID ( 3,
21)
Sampletime... JUN 13,2000 15:31:47
---------------- LEVEL 2 -----------------I-Frames
S-Frames
U-Frames
Sent
227
890
9
Rcvd
220
898
9
------------------------ LEVEL 2
SABM
DISC
Sent
7
0
Rcvd
1
1
Sent
Rcvd
RNR
0
0
REJ
0
0
DETAIL ----------------------------------UA
DM
CMDR
RR
0
2
0
890
1
6
0
898
SREJ
0
0
I-FRM
227
220
I-FRM(P)
0
0
---------------------------- DRIVER ---------------------------------------Total Frms..
2000 Line Quality..
100 No Buffer...
0
Err Frms....
0 BCC Errs......
0 Modem Errs..
0
Rcv OverRun
+0
------------------------- CLIP SPECIFIC -----------------------------------FCS Errs....
0 Addr Errs.....
0 Length Errs.
0
Rcv Abort...
0 Timeout.......
5 No Buffer...
0
CTS State...
OFF DSR State.....
OFF DCD State...
ON
Expand Configuration and Management Manual—523347-008
15 -86
Subsystem Control Facility (SCF) Commands
SWAN Concentrator Lines
PPID
is the primary process ID.
BPID
is the backup process ID.
Resettime
is the last timestamp that the statistics counters were reinitialized.
Sampletime
is the last timestamp that the statistics were collected.
LEVEL 2
shows the counts of the Layer 2 frames sent and received by this input-output
process (IOP) since statistics were last reset using the STATS RESET command
or since the line-handler process was started. The headings refer to the Expand
frame types, which are based on High-Level Data-Link Control (HDLC) protocol
definitions.
I-Frames
are information frames. This number is the total of the Information Frames
(I-FRM) and Information Frame with Poll Bit (I-FRM(P)) frame counts in the
LEVEL 2 DETAIL set of statistics in this display.
S-Frames
are supervisory frames. This number is the total of the Receive Ready (RR),
Receive Not Ready (RNR), Reject (REJ), and Selective Reject (SREJ) frames
transmitted since the last time the statistics were reset. SREJ frames apply
only to satellite-connect lines.
U-Frames
are unnumbered (nonsequenced) frames. This number is the total of the Set
Asynchronous Balanced Mode (SABM), Disconnect (DISC), and Unnumbered
Acknowledgment (UA) frame counts in the LEVEL 2 DETAIL set of statistics
in this display. The Disconnect Mode (DM) and Command Reject (CMDR)
frame counts are not included in the U-frames count since the last time the
statistics were reset.
Expand Configuration and Management Manual—523347-008
15 -87
Subsystem Control Facility (SCF) Commands
SWAN Concentrator Lines
LEVEL 2 DETAIL
is the number of Expand frames sent and received through this input-output
process (IOP), shown by frame type. If your system receives a large number of
SABM, DISC, RR, or I-FRM(P) frames relative to the total number of information
frames (I-Frames), your system might have a noisy line. Refer to Section 21,
Troubleshooting, for information on troubleshooting Layer 2 problems.
SAMB
specifies set asynchronous balanced mode.
DISC
specifies disconnect.
UA
specifies unnumbered acknowledgment frame counts.
DM
specifies disconnect mode.
CMDR
specifies command reject frame counts.
RR
specifies receive ready frames.
RNR
specifies receive not ready frames.
REJ
specifies reject frames.
SREJ
specifies selective reject frames. These apply only to satellite-connect lines.
I-FRM
specifies information frames.
I-FRM(P)
specifies information frames with poll bit frame counts.
Expand Configuration and Management Manual—523347-008
15 -88
Subsystem Control Facility (SCF) Commands
SWAN Concentrator Lines
DRIVER
displays the counters used to account for errors in received frames. The driver
counters apply only to the link between the input-output process (IOP) and the
communications line interface processor (CLIP), that is, the CLB.
Total Frms
is the total number of frames that have been transmitted and received between
the communications access process (CAP) and the CLIP since THRESHOLD
number of frames was last transmitted. THRESHOLD applies only to lines
attached to the SWAN concentrator.
Line Quality
is the line-quality value computed every 500 frames. This value is not alterable.
Line quality is computed using the following formula:
100 * (( TOTAL FRAMES - ERROR FRAMES ) / TOTAL FRAMES)
Line Quality reports a value below 100 only when the result of the formula
is 95 or less; that is, when less than 95 percent of the packets are error-free.
Low line quality generally indicates a Layer 2 problem. Refer to Section 21,
Troubleshooting, for Layer 2 troubleshooting information.
No Buffer
is the number of times read buffer space for the driver could not be obtained in
order to read a frame since statistics were reset using the STATS RESET
command.
Err Frms
is the number of times the Layer 2 timer expired when the line was up and not
idle, plus the number of frames received with BCC errors since the
THRESHOLD number of frames was last transmitted.
BCC Errs
is the number of invalid frames received from the CSS driver since the
THRESHOLD number of frames was last transmitted.
Modem Errs
is the number of times the Carrier Detect (CD) or Data Set Ready (DSR) signal
was lost by the communications hardware device for this IOP since statistics
were last reset using the STATS RESET command or since the line-handler
process was started.
Expand Configuration and Management Manual—523347-008
15 -89
Subsystem Control Facility (SCF) Commands
SWAN Concentrator Lines
Rcv OverRun
is the number of frames received that were longer than the maximum frame
size expected since statistics were last reset using the STATS RESET
command or since the line-handler process was started. This problem is
caused by the loss of modem synchronization.
CLIP SPECIFIC
displays error counts on frames received from the modem and reported by the
HDLC protocol running in the CLIP, since statistics were last reset using the STATS
RESET command or since the line-handler process was started.
FCS Errs
is the number of Frame Checksum (FCS) errors detected in frames received
from the modem.
Addr Errs
is the number of frames received with the wrong address field detected by the
Layer 2 protocol running in the CLIP.
Length Errs
is the number of U-frames and S-frames received that were longer than the
expected frame size.
Rcv Abort
is the number of frames that ended in the abort sequence.
Timeout
is the number of times a frame went unacknowledged for a user-specified
amount of time (Layer 2 T1 timer).
No Buffer
is the number of frames that arrived while all CLIP buffers were full and before
the IOP could process them. The IOP disables READ until space is available.
CTS State
is the state (ON or OFF) of the Clear To Send (CTS) signal.
DSR State
is the state (ON or OFF) of the Data Set Ready (DSR) signal.
DCD State
is the state (ON or OFF) of the Data Carrier Detect (DCD) signal.
Expand Configuration and Management Manual—523347-008
15 -90
Subsystem Control Facility (SCF) Commands
Considerations
Considerations
You can display statistics for several lines with a single STATS LINE command by
specifying multiple LINE objects using parentheses as follows:
LINE ( line-name , line-name [ , line-name ] ... )
Examples
The following SCF command displays the statistical information for a line named
$LHSL1:
-> STATS LINE $LHSL1
The following SCF command displays the statistical information for two lines named
$LHSL2 and $LHSL3:
-> STATS LINE ($LHSL2,$LHSL3)
STATS PROCESS Command
The STATS PROCESS command displays statistical information about the network
control process ($NCP).
Depending on the option you choose, the STATS command for $NCP displays the
following statistics information:
•
•
Detailed packet statistics that represent the communications occurring between
two specified systems in the network
Aggregate packet statistics occurring at the specified system
The STATS command for the network control process has the following syntax:
STATS [
[
[
[
/
,
,
,
OUT file-spec / ] PROCESS $NCP
{ NETFLOW | LOCALFLOW } ]
AT { system-list | * } ]
TO { system-list | * } ]
/ OUT file-spec /
causes any SCF output generated for the command to be directed to the specified
file.
{ NETFLOW | LOCALFLOW }
NETFLOW displays packet statistics that represent the communications occurring
between two specified systems in the network.
LOCALFLOW displays aggregate packets statistics occurring at the specified
systems.
Expand Configuration and Management Manual—523347-008
15 -91
Subsystem Control Facility (SCF) Commands
STATS PROCESS Command
AT { system-list | * }
where
system-list
is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).
sys-a
is { \system-name | system-number }.
sys-b
is { \system-name | system-number }.
sys-c
is { \system-name | system-number }.
If the NETFLOW option is chosen, only one system name or number can be
specified.
If the AT option is omitted, the SCF target system name is used.
If * is specified and the LOCALFLOW option is chosen, the aggregate packet
statistics occurring at all accessible systems in the network are displayed.
TO { system-list | * }
where
system-list
is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).
sys-a
is { \system-name | system-number }.
sys-b
is { \system-name | system-number }.
sys-c
is { \system-name | system-number }.
This parameter is valid only when the NETFLOW option is specified. It results in
the display of packet statistics for all systems specified in the TO parameter, as
viewed from the system specified in the AT parameter.
If the TO parameter is omitted and the NETFLOW option is specified, the status of
the entire network is displayed, as viewed from the system specified in the AT
parameter.
Expand Configuration and Management Manual—523347-008
15 -92
STATS PROCESS Command
Subsystem Control Facility (SCF) Commands
Similarly, if * is specified and the NETFLOW option is specified, the status of the
entire network is displayed, as viewed from the system specified in the AT
parameter.
Assume that you have entered the following command:
-> STATS PROCESS $NCP, NETFLOW, AT \N1,
TO ( 2, 4, 5, 6, 7, 9, 10, 13, 14, 15)
The resulting display has the format as shown in Example 15-28 (example display of
$NCP statistics with NETFLOW option):
Example 15-28. STATS PROCESS $NCP Command, NETFLOW Option
->STATS PROCESS $NCP, NETFLOW, AT \N1, TO ( 2, 4, 5, 6, 7, 9, 10, 13, 14, 15)
EXPAND
Stats Process $NCP, NETFLOW
Sampletime....
JUN
8,2000 20:20:1
NETWORK
2
4
5
6
7
9
10
13
14
15
SYSTEM
\NODEB
\NODET
\NODEC
\NODER
\NODEA
\NODEH
\NODEW
\NODEX
\NODET
\NODE1
TOTAL
LINKS-SENT
469
0
0
0
47
6
0
0
0
0
STATISTICS AT
TOTAL
PKTS-SENT
1133
0
0
0
110
165
0
0
0
0
\N1
(003)
TOTAL
LINKS-RCVD
102
0
0
0
8
54
0
0
0
0
TOTAL
PKTS-RCVD
1132
0
0
0
110
114
0
0
0
0
Sampletime
is the last time that the STATS command was performed.
NETWORK STATISTICS AT \N1 (003)
is the name and number of the system from which the network is viewed.
SYSTEM
lists the system numbers and names that communicated with the system specified
in the AT parameter.
TOTAL LINKS-SENT
reports the total number of link requests issued by this system to a selected system
since the line-handler process was started.
Expand Configuration and Management Manual—523347-008
15 -93
STATS PROCESS Command
Subsystem Control Facility (SCF) Commands
TOTAL PKTS-SENT
reports the total number of packets sent from this system to a selected system
since the line-handler process was started.
TOTAL LINKS-RCVD
reports the total number of link requests received by this system from a selected
system since the line-handler process was started.
TOTAL PKTS-RCVD
reports the total number of packets received by this system from a selected system
since the line-handler process was started.
Assume that you have entered the following command:
-> STATS PROCESS $NCP, LOCALFLOW, AT (\NODEC,\NODET,5,6,7,9)
The resulting display has the format as shown in Example 15-29:
Example 15-29. STATS PROCESS $NCP Command, LOCALFLOW Option
->STATS PROCESS $NCP, LOCALFLOW, AT (\NODEC,\NODET,5,6,7,9)
EXPAND
Stats Process $NCP, LOCALFLOW
Sampletime....
JUN
9, 2000 20:20:18
AGGREGATE PACKET STATISTICS
SYSTEM
2 \NODEC
4 \NODET
5 \NODEW
6 \NODER
7 \NODEA
9 \NODEH
TOTAL
PKTS-SENT
23784
14567
26735
31765
24567
30921
TOTAL
PKTS-RCVD
20874
32421
23451
26547
34582
28906
TOTAL
PASSTRU-SENT
9876
7289
10002
8902
5901
9876
TOTAL
PASSTRU-RCVD
1132
28292
10627
9028
8976
11192
Sampletime
is the last time that the STATS command was performed.
SYSTEM
is a list of the system numbers and names for which the aggregate packet statistics
are displayed.
TOTAL PKTS-SENT
reports the total number of packets sent by this system.
Expand Configuration and Management Manual—523347-008
15 -94
STATUS Command
Subsystem Control Facility (SCF) Commands
TOTAL PKTS-RCVD
reports the total number of packets received by this system.
TOTAL PASSTRU-SENT
reports the total number of passthrough packets forwarded from this system.
TOTAL PASSTRU-RCVD
reports the total number of passthrough packets received by this system.
STATUS Command
The STATUS command displays the dynamic state, last error, and modifiable values of
the specified object. It also displays specific subsystem attributes and values. STATUS
is a nonsensitive command.
The STATUS command has the following syntax:
STATUS [ / OUT file-spec / ]
{ PATH path-name | LINE line-name }
[, DETAIL ]
/ OUT file-spec /
causes any SCF output generated for the command to be directed to the specified
file.
PATH path-name
indicates the device name of a path.
LINE line-name
indicates the device name of a line.
STATUS PATH Command
The display for a path without the DETAIL option has the format as shown in
Example 15-30:
Example 15-30. STATUS PATH Command
-> STATUS PATH $LHPATH2
EXPAND
Name
$LHPATH2
Status PATH
State
STARTED
PPID
1, 20
BPID
2, 26
Lines #
1
Expand Configuration and Management Manual—523347-008
15 -95
STATUS PATH Command
Subsystem Control Facility (SCF) Commands
Name
is the device name of the path.
State
indicates the summary state of the path. The path is in the STARTED, STARTING,
DIAGNOSING (for SWAN concentrators only), or STOPPED state.
PPID
is the primary process ID.
BPID
is the backup process ID.
Lines #
reports the total number of lines associated with the path.
The display for a path with the DETAIL option has the format as shown in
Example 15-31:
Example 15-31. STATUS PATH, DETAIL Command
-> STATUS PATH $PATM4WI, DETAIL
EXPAND
Detailed Status
PPID........ ( 1,
295)
State.......
STARTED
Trace Status
OFF
Line LDEVs..
148 184
Trace File Name....
PATH $PATM4WI
BPID........... ( 2,
Number of Lines..
Superpath........
189 347
none
270)
4
OFF
PPID
is the primary process ID.
BPID
is the backup process ID.
State
indicates the summary state of the path. The path is in the STARTED, STARTING,
DIAGNOSING (for SWAN concentrators only), or STOPPED state.
Number of Lines
reports the total number of lines associated with the path.
Expand Configuration and Management Manual—523347-008
15 -96
Considerations
Subsystem Control Facility (SCF) Commands
Trace Status
indicates whether the path is being traced.
Superpath
reports ON if the path is currently a member of a multi-CPU path and OFF if it is
not. The Expand line-handler process at the other end of the path must be
configured with SUPERPATH_ON or the multi-CPU path feature will not be
enabled. The configured value can be displayed using the INFO PATH command.
Line LDEVs
displays the LDEV identifiers for all the lines (up to eight) associated with the path.
Trace File Name
the name of the trace file specified in the SCF TRACE command.
Considerations
You can display the status information for several paths with a single STATUS PATH
command by specifying multiple PATH objects using parentheses as follows:
PATH ( path-name , path-name [ , path-name ] ... )
Examples
The following SCF command summarizes the status on path $PATH1:
-> STATUS PATH $PATH1
The following SCF command gives a detailed display of the status on path $PATH1:
-> STATUS PATH $PATH1, DETAIL
The following SCF command summarizes the status on paths $PATH2 and $PATH3:
-> STATUS PATH ($PATH2,$PATH3)
STATUS LINE Command
The display for a LINE object without the DETAIL option has the format as shown in
Example 15-32:
Example 15-32. STATUS LINE Command
-> STATUS LINE $SWNLCW1
EXPAND
Name
$SWNLCW1
Status LINE
State Status
STARTED READY
PPID
2, 20
BPID
3, 21
CIU-Path
A
Expand Configuration and Management Manual—523347-008
15 -97
ConMgr-LDEV
70
STATUS LINE Command
Subsystem Control Facility (SCF) Commands
Name
is the device name of the line.
State
indicates the summary state of the line. The line is in either the STARTED or
STOPPED state.
STATUS
indicates the status of the line: ready or not ready.
PPID
is the primary process ID.
BPID
is the backup process ID.
CIU-Path
indicates which ServerNet wide area network (SWAN) concentrator path (A or B) is
being used by this line to communicate with the SWAN concentrator. This field only
applies to lines connected to a SWAN concentrator.
ConMgr-LDEV
is the logical device (LDEV) number of the concentrator manager (ConMgr)
process. The ConMgr process is part of the WAN subsystem. This field only
applies to lines connected to a ServerNet wide area network (SWAN) concentrator.
For direct-connect and satellite-connect line-handler processes, the display for a LINE
object with the DETAIL option has the format as shown in Example 15-33:
Example 15-33. STATUS LINE, DETAIL Command, Direct- and Satellite-Connect
Line-Handler Processes
-> STATUS LINE $SWNYE2, DETAIL
EXPAND
Detailed Status
PPID...............
State..............
Trace Status.......
ConMgr-LDEV........
SWAN Track Id......
Line...............
IP Address.........
Trace File Name....
LINE $SWNYE2
( 2,
327)
STARTED
OFF
72
X017NU
1
172.17.208.82
none
BPID.................
Path LDEV............
Clip Status..........
Status
Clip.................
Path.................
Effective line priority
Expand Configuration and Management Manual—523347-008
15 -98
( 3,
277)
303
LOADED
READY
1
B
1
Subsystem Control Facility (SCF) Commands
STATUS LINE Command
PPID
is the primary process ID.
BPID
is the backup process ID.
State
indicates the summary state of the line. The line is in either the STARTED or
STOPPED state.
Path LDEV
contains the logical device (LDEV) number of the path associated with this line.
Trace Status
indicates whether the line is being traced.
Clip Status
indicates the state of the communications line interface processor (CLIP) on the
ServerNet wide area network (SWAN) concentrator used by this line.
ConMgr-LDEV
is the logical device (LDEV) number of the concentrator manager (ConMgr)
process. The ConMgr process is part of the WAN subsystem.
STATUS
indicates the status of the line: ready or not ready.
SWAN Track Id
is the configuration track ID of the SWAN concentrator used by this line. Each
SWAN concentrator is assigned a unique configuration track ID.
Clip
indicates which communications line interface processor (CLIP) (0, 2, or 3) on the
SWAN concentrator is used by this line.
Line
indicates which line (0 or 1) in the CLIP on the SWAN concentrator is used by this
line.
Path
indicates which SWAN concentrator path (A or B) is being used by this line to
communicate with the SWAN concentrator.
Expand Configuration and Management Manual—523347-008
15 -99
Subsystem Control Facility (SCF) Commands
STATUS LINE Command
IP Address
is the Internet Protocol (IP) address associated with the SWAN concentrator path
(A or B) being used by this line to communicate with the SWAN concentrator. Each
SWAN path is assigned a unique IP address.
Effective line priority
indicates the effective priority of the line.
Trace File Name
the name of the trace file specified in the SCF TRACE command.
For an Expand-over-IP, Expand-over-ATM, Expand-over-ServerNet, Expand-over-FOX,
or Expand-over-NAM line-handler process, the display for a LINE object with the
DETAIL option has the format as shown in Example 15-34:
Example 15-34. STATUS LINE, DETAIL Command, LINE Object
-> STATUS LINE $IPWIL1, DETAIL
EXPAND
Detailed Status
PPID...............
State..............
Trace Status.......
Detailed State.....
Detailed Info...
Trace File Name....
LINE $IPWIL1
( 2,
32) BPID.................
STARTED Path LDEV............
OFF Effective line priority
CONNECTED Status
None
\NODEA.$DATA00.MIKE.TRCFOX
( 3,
29)
212
1
READY
PPID
is the primary process ID.
BPID
is the backup process ID.
State
indicates the summary state of the line. The line is either in the STARTED or
STOPPED state.
Path LDEV
contains the logical device (LDEV) number of the path associated with this line.
Trace Status
indicates whether the line is being traced.
Effective line priority
indicates the effective priority of the line.
Expand Configuration and Management Manual—523347-008
15- 100
Subsystem Control Facility (SCF) Commands
STATUS LINE Command
Detailed State
indicates a more detailed state. The detailed states are as follows:
ACCEPT
indicates that a switched virtual circuit (SVC) connection has been accepted
from the remote system. This state applies to Expand-over-ATM line-handler
processes that use SVC connections only.
BINDING
indicates that the Expand-over-IP or line-handler process is binding to the local
NonStop TCP/IP process, that the Expand-over-ATM line-handler process is
binding to the configured permanent virtual circuit (PVC) name, or that the
Expand-over-NAM line-handler process is binding to the local network access
method (NAM) process.
CALLING
indicates that the Expand-over-ATM line-handler process is attempting to
establish a switched virtual circuit (SVC) connection to the remote system. This
state applies to Expand-over-ATM line-handler processes that use SVC
connections only.
CONNECTED
indicates that a connection has been established.
CONNECTING
indicates that the Expand line-handler process is attempting to connect to the
remote (destination) Expand line-handler process.
DISCONNECTING
indicates that the inactivity timer expired for the Expand line-handler process; it
sent a disconnect message, and is waiting for a reply.
DOWN
indicates that the Layer 2 functions of the Expand line-handler process are
down.
DOWN SOCKET
an internal state that should not persist. This state applies to Expand-over-IP
line-handler processes only.
DOWN WAIT
an internal state that should not persist. This state applies to Expand-over-IP
line-handler processes only.
Expand Configuration and Management Manual—523347-008
15- 101
Subsystem Control Facility (SCF) Commands
STATUS LINE Command
INACTIVE
indicates that the Expand line-handler process is inactive. It is either waiting for
data to send or is waiting for an active connect from the other side.
LISTEN
indicates that the Expand-over-ATM line-handler process is waiting for
switched virtual circuit (SVC) connection establishment from the remote
system. This state applies to Expand-over-ATM line-handler processes that
use SVC connections only.
PASSIVE
indicates that the Expand line-handler process is waiting for the remote
(destination) Expand line-handler process to initiate a connection.
QUERY
indicates that the Expand line-handler process is connected to the remote
(destination) Expand line-handler process, but no data has been received
within the inactivity interval (SCF TIMERPROBE attribute). The Expand linehandler process is sending Probe messages to the remote Expand line-handler
process to verify that it is operational.
RECONNECTING
indicates that the Expand line-handler process received data while it was
inactive, sent an active connect, and is waiting for a reply.
REPASSIVE
indicates that the Expand line-handler process received data while it was
inactive, sent an passive connect, and is waiting for a reply.
SETOPT_CALLING
an internal state that should not persist. This state applies to Expand-over-ATM
line-handler processes only.
SETOPT_LISTEN
an internal state that should not persist. This state applies to Expand-over-ATM
line-handler processes only.
SOCKET_REUSE
an internal state that should not persist. This state applies to Expand-over-IP
line-handler processes only.
Expand Configuration and Management Manual—523347-008
15- 102
STATUS LINE Command
Subsystem Control Facility (SCF) Commands
SOCKET SETUP
an internal state that should not persist. This state applies to Expand-over-IP
line-handler processes only.
SOCKET_SPACE
an internal state that should not persist. This state applies to Expand-over-IP
line-handler processes only.
WAIT
indicates that the Expand line-handler process is waiting for another process or
subsystem. Refer to the Detailed Info field for more information.
Status
indicates the readiness status of the line or whether there is an error.
Detailed Info
displays the last error message returned to the Expand-over-IP or Expand-overATM line-handler process; this field is not displayed for Expand-over-NAM,
Expand-over-ServerNet, or Expand-over-FOX line-handler processes. This field
provides more information about the current detailed state. Each message returned
to this field corresponds to an Event Management Service (EMS) event number
generated by the Expand subsystem. Table 15-7 lists the messages and their
corresponding event numbers.
Trace File Name
the name of the trace file specified in the SCF TRACE command.
Table 15-7. Messages and Corresponding Event Numbers (page 1 of 2)
Message
Event Number
Internal error nnn, Info %Hxxx, Loc %yyy
8
Shared Memory error nnn, Info %Hxxx, Loc %yyy
9
Unexpected QIO event, Info %Hxxx, Loc %yyy
10
TCP error nnn, Info %Hxxx, Loc %yyy
11
Response error nnn, Info %Hxxx, Loc %yyy
12
Ownership error
13
Associate TCP process unavailable
14
Shared memory system unavailable
15
Connect retries exhausted
16
Timeout waiting for assoc TCP process, Info %Hxxx, Loc %yyy
17
ATM subsystem error nnn, Info %Hxxx, Loc %yyy
18
Expand Configuration and Management Manual—523347-008
15- 103
Considerations
Subsystem Control Facility (SCF) Commands
Table 15-7. Messages and Corresponding Event Numbers (page 2 of 2)
Message
Event Number
ATM subsystem unavailable
19
PVC unavailable, error nnn
20
SVC unavailable, error nnn
21
Associate NAM process unavailable
23
NAM process error nnn
24
NAM process timeout
25
NAM service down
26
ATM LIF error, error nnn
28
ATM LIF not found
29
ATM LIF is stopped
30
ATM LIF access state is down
31
ATM LIF inaccessible
32
Refer to the Operator Messages Manual for cause, effect, and recovery information for
the event numbers generated by the Expand subsystem.
Considerations
You can display the status information for several lines with a single STATUS LINE
command by specifying multiple LINE objects using parentheses as follows:
LINE ( line-name , line-name [ , line-name ] ... )
Examples
The following SCF command summarizes the status on line $LINE1:
-> STATUS LINE $LINE1
The following SCF command gives a detailed display of the status on path $LINE1:
-> STATUS LINE $LINE1, DETAIL
The following SCF command summarizes the status on paths $LINE2 and $LINE3:
-> STATUS PATH ($LINE2,$LINE3)
Expand Configuration and Management Manual—523347-008
15- 104
Subsystem Control Facility (SCF) Commands
STOP Command
STOP Command
The STOP command terminates the activity of an object normally. It nondisruptively
deletes all connections to and from an object. Upon successful completion, configured
objects are left in the STOPPED state and nonconfigured objects are deleted. This is a
sensitive command.
The STOP command has the following syntax:
STOP { PATH path-name | LINE line-name }
Considerations
•
•
•
•
If PATH is the object type, all lines associated with the path are stopped.
If LINE is the object type, only the line is stopped.
The STOP command only stops objects that are not actively used. If you want to
stop activity on a line or path object that is still active, use the ABORT command as
described in ABORT Command on page 15-8.
You can stop several paths or lines with a single STOP PATH or STOP LINE
command by specifying multiple PATH or LINE objects using parentheses as
follows:
PATH ( path-name , path-name [ , path-name ] ... )
LINE ( line-name , line-name [ , line-name ] ... )
Examples
The following SCF command stops the line named $LHCMP2:
-> STOP LINE $LHCMP2
The following SCF command stops all lines associated with the path named $PTS:
-> STOP PATH $PTS
The following SCF command stops the lines named $LHCMP3 and $LHCMP4:
-> STOP LINE ($LHCMP3,$LHCMP4)
Expand Configuration and Management Manual—523347-008
15- 105
Subsystem Control Facility (SCF) Commands
TRACE Command
TRACE Command
The TRACE command can request the capture of target-defined data items, alter trace
parameters, and end tracing. TRACE is a sensitive command.
An SCF trace produces a trace file that can be displayed using the commands
available in the PTrace program. The trace file is created by SCF. The PTrace program
is described in the PTrace Reference Manual and in Section 16, Tracing.
The TRACE command has the following syntax for tracing Expand paths:
TRACE [
[
[
[
[
[
[
[
[
/
,
,
,
,
,
,
,
,
OUT file-spec / ] PATH path-name
BACKUP]
COUNT count ]
NOCOLL ]
PAGES pages ]
RECSIZE size]
SELECT select-spec ]
TO file-spec ]
WRAP ]
or
TRACE PATH path-name , STOP
The TRACE command has the following syntax for tracing Expand lines:
TRACE [
[
[
[
[
[
[
[
[
/
,
,
,
,
,
,
,
,
OUT file-spec / ] LINE line-name
BACKUP]
COUNT count ]
NOCOLL]
PAGES pages ]
RECSIZE size]
SELECT select-spec ]
TO file-spec ]
WRAP ]
or
TRACE LINE line-name , STOP
Expand Configuration and Management Manual—523347-008
15- 106
Subsystem Control Facility (SCF) Commands
TRACE Command
The TRACE command has the following syntax for tracing the network control process
($NCP):
TRACE [
[
[
[
[
[
[
[
/
,
,
,
,
,
,
,
OUT file-spec / ] PROCESS $NCP
BACKUP ]
COUNT count ]
NOCOLL]
PAGES pages ]
RECSIZE size]
SELECT select-spec ]
TO file-spec ]
or
TRACE PROCESS $NCP , STOP
/ OUT file-spec /
causes any SCF output generated for the command to be directed to the specified
file.
PATH path-name
is the device name of the path to be traced.
LINE line-name
is the device name of the line to be traced.
BACKUP
specifies that only the backup path should have its trace started or stopped. If
omitted, specifies that only the primary line is to be traced. The object must be
running as a process pair if this syntax is used. If the primary path is being traced
when a takeover by the backup path occurs, the trace of the same path continues.
However, most events that were being traced prior to the path switch will no longer
be traced because the path being traced is no longer the primary. If neither path is
designated, the primary path is traced.
COUNT count
count is an integer in the range -1 to (32K -1). It specifies the number of trace
records to be captured. If COUNT is not specified (or is specified as -1), records
are accumulated until the trace is stopped.
NOCOLL
indicates that the trace collector process should not be initiated. The disk file is to
be written to by the operating system.
Expand Configuration and Management Manual—523347-008
15- 107
TRACE Command
Subsystem Control Facility (SCF) Commands
PAGES pages
pages is an integer in the range 4 to 64. PAGES controls how much space, in
units of pages, is allocated in the extended data segment used for tracing. PAGES
may be specified only when the trace is being initiated. The default value is 64
pages.
RECSIZE size
size is an integer in the range 16 to 4050. It controls the length of the data in the
trace data records. The trace header is not included in RECSIZE. The default is
120 bytes. 8 bytes are used for the header, and 120 bytes are used for trace data.
A RECSIZE of 500 is recommended for $NCP traces. If PATHBLOCKBYTES or
PATHPACKETBYTES is enabled, a RECSIZE greater than the
PATHBLOCKBYTES or PATHPACKETBYTES is recommended for Expand traces
in order to avoid truncating the data records.
SELECT select-spec
select-spec is one of the parameter specification combinations described in
Table 15-8, Table 15-9, or Table 15-10. You can specify either the keyword or the
bit number.
The select-spec for $NCP is described in Table 15-8.
Table 15-8. $NCP Trace Records
Mask
Trace Record
Keyword
Bits
Meaning
Type (decimal)
L0
0
Packet sent by $NCP
0
0
Packet received by $NCP
1
L2
2
Layer 2 events
2
L4
4
Layer 4 events
4
4
System abort message
6
4
System connect message
6
0-31
Sets all trace record types
ALL
The select-spec for the LINE object is described in Table 15-9.
Expand Configuration and Management Manual—523347-008
15- 108
TRACE Command
Subsystem Control Facility (SCF) Commands
Table 15-9. LINE Object Trace Records
Mask
Trace Record
Keyword
Bits
Meaning
Type (decimal)
L0
0
Frames out, nonextended1
0
0
Frames in, nonextended1
1
0
Frames out, extended1
7
0
Frames in, extended1
8
L2
2
Layer 2 events
2
L4
4
Layer 4 events2
4
L5
5
Security events
198
CLBI
10
CLB inbound frames3
248
CLBO
11
CLB outbound frames3
249
CLIPDI
15,16
CLIP inbound frames3
255
CLIPDO
15,17
CLIP outbound frames3
255
CLIPL2
15,21
CLIP Layer 2 events3
255
ALL
0-31
Sets all 32 bits
1. Applies only to lines not attached to a ServerNet wide area network (SWAN) concentrator.
2. Applies only to $NCP.
3. Applies only to lines attached to a SWAN concentrator.
The select-spec for PATH objects is described in Table 15-10.
Table 15-10. PATH Object Trace Records
Mask
Trace Record
Keyword
Bits
Meaning
Type (decimal)
L0
0
Frames out, nonextended*
0
0
Frames in, nonextended*
1
0
Frames out, extended*
7
0
Frames in, extended*
8
L3
3
Layer 3 events
3
L4
4
Layer 4 events
4
4
Line-handler process to $NCP
message
5
4
System abort messages
6
L5
5
Security events
198
ALL
0-31
Sets all 32 bits
*Applies only to paths not attached to a ServerNet wide area network (SWAN) concentrator.
Expand Configuration and Management Manual—523347-008
15- 109
Subsystem Control Facility (SCF) Commands
Considerations
TO file-spec
file-spec specifies the file to which tracing is to be initiated. The file may have
been previously created by you as an unstructured file with file code 0.
WRAP
causes the trace segment data to wrap instead of stopping the trace when it
reaches the end of file. The default is FALSE.
STOP
discontinues the trace currently in progress.
Considerations
•
•
•
•
•
•
•
Unless otherwise instructed by your HP representative, select all of the trace
record types. This is the default.
The PROCESS name of the network control process is always $NCP.
The keyword L0 applies to both LINE and PATH objects. When L0 is used with
LINE, all frames sent and received on that line are traced. When L0 is used with
PATH, all frames for which this system is either the source or the destination are
traced in the PATH trace.
The keyword ALL selects all mask bits.
Selecting a keyword that does not apply to the object type specified has no effect.
All keywords apply when the object is a single-line path. For keyword L0, it is
treated as a LINE object.
You can trace several objects with a single TRACE command by specifying
multiple objects using parentheses as follows:
PATH ( path-name , path-name [ , path-name ] ... )
LINE ( line-name , line-name [ , line-name ] ... )
Examples
The following SCF command initiates a trace of communications line interface
processor (CLIP) inbound and outbound frames for $LINE1. One-thousand trace
records are captured. The trace records are written to the file X1:
-> TRACE LINE $LINE1, TO X1,SELECT(CLIPDI,CLIPDO), COUNT 1000
The following SCF command terminates an existing trace of path $PATH1:
-> TRACE PATH $PATH1, STOP
The following SCF command initiates a trace of the network control process:
-> TRACE PROCESS $NCP, TO NCPTRC, SELECT ALL, RECSIZE 500, WRAP
Expand Configuration and Management Manual—523347-008
15- 110
Subsystem Control Facility (SCF) Commands
VERSION Command
The following SCF command initiates a trace of two lines named $LINE2 and $LINE3:
-> TRACE LINE ($LINE2,$LINE3)
VERSION Command
The VERSION command displays the version level of the Expand manager process
($ZEXP), the network control process ($NCP), or an Expand line-handler process.
VERSION is a nonsensitive command.
The VERSION command has the following syntax:
VERSION [ / OUT file-spec / ] PROCESS
{ process-name | $NCP | $ZEXP }
/ OUT file-spec /
causes any SCF output generated for the command to be directed to the specified
file.
process-name
is the device name of an Expand line or path.
Considerations
•
•
The VERSION command helps in troubleshooting. When reporting a suspected
Expand problem to HP, include the versions of $ZEXP, $NCP, and an Expand linehandler process.
You can display version information for several objects with a single VERSION
command by specifying multiple objects using parentheses as follows:
PROCESS ( object-name , object-name [ , object-name ] ... )
Examples
The following examples show the version information returned for $ZEXP, $NCP, and a
line-handler process.
Expand Configuration and Management Manual—523347-008
15 -111
Subsystem Control Facility (SCF) Commands
VERSION PROCESS $ZEXP Command
VERSION PROCESS $ZEXP Command
Example 15-35 shows the displays for the VERSION PROCESS $ZEXP command:
Example 15-35. VERSION PROCESS $ZEXP Command
-> VERSION PROCESS $ZEXP
VERSION PROCESS \NODEA.$ZEXP: EXPAND (MGR) (17MAR00)
T9117G06 - (30JAN00) -
-> VERSION PROCESS $ZEXP, DETAIL
Detailed VERSION PROCESS \NODEA.$ZEXP
SYSTEM \NODEA
EXPAND (MGR) T9117G06 - (30JAN00) - (17MAR00)
GUARDIAN - T9050 - (Q06)
SCF KERNEL - T9082G02 - (26JUN00) (20MAR00)
EXPAND PM - T9117G06 - (30JAN00) - (17MAR00)
VERSION PROCESS $NCP Command
Example 15-36 shows the displays for the VERSION PROCESS $NCP command:
Example 15-36. VERSION PROCESS $NCP Command
-> VERSION PROCESS $NCP
VERSION PROCESS \NODEA.$NCP: EXPAND (NCP) - T9057G06 - (25JUL00_31MAY00_AER)
-> VERSION PROCESS $NCP, DETAIL
Detailed VERSION PROCESS \NODEA.$NCP
SYSTEM \NODEA
EXPAND (NCP) - T9057G06 - (25JUL00_31MAY00_AER)
GUARDIAN - T9050 - (Q06)
SCF KERNEL - T9082G02 - (26JUN00) (20MAR00)
EXPAND PM - T9117G06 - (30JAN00) - (17MAR00)
Expand Configuration and Management Manual—523347-008
15- 112
Subsystem Control Facility (SCF) Commands
VERSION PROCESS LINE Command
VERSION PROCESS LINE Command
Example 15-37 shows the display for the VERSION PROCESS LINE command:
Example 15-37. VERSION PROCESS LINE Command
-> VERSION PROCESS $IPWIL1
VERSION PROCESS \NODE.$IPWIL1: EXPAND (LH) - T9057G06 - (25JUL00_31MAY00_AER)
-> VERSION PROCESS $IPWIL1, DETAIL
Detailed VERSION PROCESS \NODE.$IPWIL1
SYSTEM \NODE
EXPAND (LH) - T9057G06 - (25JUL00_31MAY00_AER)
GUARDIAN - T9050 - (Q06)
SCF KERNEL - T9082G02 - (26JUN00) (20MAR00)
EXPAND PM - T9117G06 - (30JAN00) - (17MAR00)
Expand Configuration and Management Manual—523347-008
15- 113
Subsystem Control Facility (SCF) Commands
VERSION PROCESS LINE Command
Expand Configuration and Management Manual—523347-008
15- 114
16
Tracing
This section describes the tracing process when the SCF TRACE command is used
with commands available in the PTrace facility. The SCF TRACE command allows you
to select the records that you want written to a disk file. PTrace commands allow you to
select which of those records you want formatted and sent to an output device. The
output device can be a terminal, spooler, or printer.
The following topics are described in this section:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Why Tracing Is Important on page 16-2
How to Use Tracing on page 16-2
Tracing Using SCF on page 16-3
PTrace Command Overview on page 16-5
FILTER Command on page 16-6
FIND Command on page 16-7
FROM Command on page 16-8
HEX Command on page 16-8
LABEL Command on page 16-9
NEXT Command on page 16-9
OCTAL Command on page 16-10
OUT Command on page 16-10
RECORD Command on page 16-11
SELECT Command on page 16-12
For general information about PTrace, refer to the PTrace Reference Manual. For more
information about the SCF TRACE command, refer to TRACE Command on
page 15-106.
Note. For the Expand subsystem, PTrace is primarily an HP internal tool. Because Expand
uses HP-proprietary protocols, internal state information is not provided to customers.
Expand Configuration and Management Manual—523347-008
16- 1
Why Tracing Is Important
Tracing
Why Tracing Is Important
Tracing allows HP personnel to see the history of a data communications link, including
significant points in the internal processing of the traced entity. Isolating a data
communications problem using an Expand trace is easier than using a system dump.
How to Use Tracing
For tracing to be effective, make sure you follow these guidelines:
•
•
•
•
Always trace both ends of a path.
Ensure that all traces for a particular problem are taken at the same time.
If the data rate is high, or if the trace is expected to run for many hours, preallocate
the file space for the trace file using the File Utility Program (FUP). A 3- or 4megabyte file is generally sufficient for all but the longest or most work-intensive
traces.
Gather a $NCP trace even if you do not believe the problem involves $NCP. It is
better to have too much information than too little.
Tracing $NCP
To start a trace of $NCP, enter
-> TRACE PROCESS $NCP, TO $file-name, SELECT ALL, WRAP, &
RECSIZE 500
To stop the trace, enter
-> TRACE PROCESS $NCP, STOP
$file-name specifies the name of the file to which the trace records will be written.
Tracing a Path or Single Line
To start a trace of a path or a single-line Expand line-handler process, enter
-> TRACE PATH $path-name, TO $file-name, SELECT ALL, WRAP
To stop the trace, enter
-> TRACE PATH $path-name, STOP
$path-name specifies the name of the path logical device or single-line Expand linehandler process. $file-name specifies the name of the file to which the trace records
will be written.
Expand Configuration and Management Manual—523347-008
16- 2
Tracing a Line in a Multi-Line Path
Tracing
Tracing a Line in a Multi-Line Path
To start a trace of a line that is part of a multi-line path, enter
-> TRACE LINE $line-name, TO $file-name, SELECT ALL, WRAP
To stop the trace, enter
-> TRACE LINE $line-name, STOP
$line-name specifies the name of the line logical device. $file-name specifies the
name of the file to which the trace records will be written.
Tracing Using SCF
To trace records, you enter the SCF TRACE command using keywords to select
records (refer to TRACE Command on page 15-106 for details about your options).
This command is sent to the Expand product module that has been bound into the
SCF Kernel. The product module converts this command into the Subsystem
Programmatic Interface (SPI) format that is understood by the Subsystem Control
Process (SCP). SCP sends a response to the product module after it receives the SPI
buffer, indicating whether the command has been accepted.
If the command is accepted by SCP, SCP translates the SPI buffer into a bit mask that
it sends to the Expand manager ($ZEXP). The Expand manager sends the bit mask to
either $NCP or the line-handler process, depending on the object type specified in the
TRACE command. The $NCP or Expand line-handler process, when it receives this bit
mask, calls the SCP trace module defined within the Expand subsystem. The SCP
trace module causes the selected records to be sent to the SCP Trace Collector.
Note. If you have selected the NOCOLL option in the TRACE command, the SCP Trace
Collector will not be initiated and the SCP Trace module in the Expand subsystem will send the
selected records directly to the disk file you have specified.
The SCP trace module in Expand continues to trace records that meet the selected
criteria until you stop the trace using the STOP keyword in the TRACE command, or
when the maximum file size has been reached and the WRAP option has not been
specified. Once you have stopped the trace, you can use the PTrace commands to
look at the records.
Enter the RUN command (explicitly or implicitly) to initiate the PTrace facility. Once
initiated, enter the FROM command, which causes the Expand product module in
PTrace to send an OPEN to the disk file specified. You can then use several of the
PTrace commands (such as RECORD, NEXT, and FIND) to send the records from the
disk to memory. If you have issued the FILTER or SELECT command, the Expand
product module will check each record sent from the disk file as a result of the
RECORD, NEXT, or FIND command to verify that it meets the criteria you have set
using the FILTER or SELECT command. Records that do not meet the criteria will not
be sent to the terminal or printer; the records will be discarded. The PTrace facility
does not function in block mode; it only functions in conversational mode.
Expand Configuration and Management Manual—523347-008
16- 3
Tracing Using SCF
Tracing
Figure 16-1 shows the relationship of the tracing process components when SCF is
used.
Figure 16-1. Tracing Process Using SCF
SCF Trace Command
for $NCP, LINE,
or PATH
SCF
Expand PM
SPI
Command
SPI
Response
SCP
Bit Mask
PTrace
Command
Expand
Manager
($ZEXP)
Selected
Trace Records
Formatted
Bit Mask
for $NCP
Bit Mask for
LINE or PATH
Expand
Line Handler
$NCP
SCP TRACE
SCP TRACE
SCF
Selected
Records
SCF
Selected
Records
SCP TRACE
COLLECTOR
Traced
Records
File-System
Procedure
Disk
File
052CDT
Filter Select
Expand PM
Trace Records
.CDD
Ptrace Facility
Expand Configuration and Management Manual—523347-008
16- 4
PTrace Command Overview
Tracing
PTrace Command Overview
When you are using the PTrace facility, consider the following:
•
•
•
You have not been provided trace-format information to read these formats
because you do not have the source code. Therefore, when reporting problems,
select the ALL option available in the SCF TRACE command.
You should always specify the source disk file using the PTrace FROM command
before any other PTrace command.
Use the SELECT and FILTER commands to format and print a subset of the
records that have been traced.
When using PTrace commands, remember that the SELECT and FILTER commands
establish criteria against which records are compared. Records that match are
formatted and displayed; those that do not are ignored. The FIND, NEXT, and
RECORD commands determine the range of records in the currently opened trace file
that will be examined.
Table 16-1 briefly describes commands that are useful when formatting Expand trace
records using the PTrace facility.
Table 16-1. PTrace Commands Summary
Command
Description
FILTER
Prevents the selected types of information within a record from being displayed
or printed to the output device.
FIND
Searches the trace records sent from the disk file for the specified string.
FROM
Opens the specified trace disk file.
HEX
Displays or prints the data portion of the trace record in hexadecimal.
LABEL
Formats state machine entries, frames, packets, message headers, and data.
NEXT
Specifies the number of records or specifies a time after which records are to
be displayed or printed.
OCTAL
Displays or prints the data portion of the trace record in octal.
OUT
Directs the trace records to a line printer or a spooler.
RECORD
Prints records within the specified range or prints all records.
SELECT
Selects records by type to be sent to the output device.
For details about the PTrace facility, refer to the PTrace Reference Manual. The
remainder of this section describes the commands that are of particular interest to
persons tracing Expand information.
Expand Configuration and Management Manual—523347-008
16- 5
FILTER Command
Tracing
FILTER Command
The FILTER command prevents the selected type of information from being sent to the
output device.
FILTER { option | option,option,...option | RESET }
option
defines the type of information you do not want to display or print to the output
device. You can specify one or more options separated by commas:
NOHDR
filters trace record header information.
NOL2
filters Layer 2 frame header information.
NOL2RR
filters Layer 2 Receive Ready (RR) frame information.
NOL3
filters packet header information.
NOL4
filters message header information.
NODATA
filters packet data.
NODIAL
filters dialect information.
RESET
resets all selection options to the default, which does not filter information.
Considerations
The PTrace facility filters the selected information types until you invoke the default,
which does not filter information. You can invoke the default in one of the following
ways:
•
•
Issue the FROM command.
Issue the FILTER command again.
Expand Configuration and Management Manual—523347-008
16- 6
Examples
Tracing
•
Issue the FILTER command with the RESET option.
If you issue the FILTER command with one set of selection options and then reissue it
with a different set of selection options, the options entered with the second FILTER
command are used to determine the trace information sent to the output device. The
previously entered selection options are overridden; selection options are not
cumulative. For example, if you enter the command FILTER NOL2,NOL3, Layer 2
frame header information and Layer 3 packet header information will not be sent to the
output device. If you then enter the command FILTER NOHDR, only trace record
header information will be filtered. Layer 2 and 3 header information will be sent to the
output device.
If you are tracing the $NCP process, note that the NOL2, NOL4, and NODATA
selection options do not apply. If you want to filter state machine information, use the
SELECT command.
Examples
The following command filters Layer 2 Receive Ready (RR):
?FILTER NOL2RR
The following command resets the filter to the default, so no information is filtered:
?FILTER RESET
FIND Command
The FIND command searches the formatted output of trace records for the specified
string of alphanumeric characters. Only records matching the SELECT and FILTER
options are examined.
F[IND]
[ [ B[OTH] ] "string" ]
BOTH
specifies that you want the search to be case-insensitive; that is, that PTrace
should treat uppercase and lowercase characters the same when searching for a
match.
string
is an optional alphanumeric string. The string can be a maximum of 80 characters.
Considerations
When you enter the FIND command with a string parameter, PTrace begins
searching at the first record in the file. If you enter the FIND command without a
string parameter, PTrace searches for the string parameter specified in the last
FIND command. In this case, PTrace begins the search at the record following the last
Expand Configuration and Management Manual—523347-008
16- 7
Examples
Tracing
record in which the previously specified string parameter was found. However, if you
enter the FIND command without a string parameter and no previous FIND
command with a string parameter has been issued, an error is returned.
While the PTrace facility processes the FIND command, trace records will not be sent
to the output device. If the specified string is found in an output line, the entire record is
sent to the output device.
Examples
The following example searches the trace file for both uppercase and lowercase
occurrences of the character string EXPAND03:
?FIND BOTH "EXPAND03"
The following example searches for the next occurrence of a previously specified
string:
?FIND
FROM Command
The FROM command causes PTrace to open the specified trace file. Each time a trace
file is opened using the FROM command, all options selected using the other PTrace
commands are reset to their defaults.
FROM file-name
file-name
specifies the name of the disk file to be opened. This file name is the one you
specified in the SCF TRACE command.
Example
?FROM $TEST.TRACE1
HEX Command
The HEX command, if set to ON, prints the data portion of a trace record, including the
record header, in hexadecimal format.
HEX
{ ON | OFF }
ON | OFF
ON enables printing in hexadecimal format. OFF disables printing in hexadecimal
format and enables printing in octal format. The default is OFF.
Expand Configuration and Management Manual—523347-008
16- 8
Example
Tracing
Example
?HEX ON
LABEL Command
The LABEL command formats state machine entries, frames, packets, message
headers, and message data when set to ON (or defaults). This command is useful only
for personnel who have source code listings.
LABEL { ON | OFF }
ON | OFF
ON enables formatting of trace record information. This is the default when first
entering PTrace. OFF disables formatting of trace record information.
Example
?LABEL OFF
NEXT Command
The NEXT command defines which records to send to the output device. You can
select the records by specifying a count and/or a timestamp. You can specify the count
by entering an integer or by pressing a function key at the 6530 terminal. Only records
matching the SELECT and FILTER options are displayed.
N[EXT] [ count ] [ AFTER timestamp
] [ F-key
]
count
is an integer that specifies the number of records to send to the output device. The
valid range is 0 through 255. If you do not specify a count, one record is sent.
timestamp
specifies a time in hh:mm:ss.tt format, where ss and tt are optional. Once a
record is found that has a timestamp greater than or equal to the timestamp
specified, the count parameter or F-key that is pressed will be used to determine
the number of records sent to the output device.
F-key
is pressed to specify the number of lines to display at the 6530 terminal. Table 16-2
lists the number of lines that are sent when specific function keys are pressed.
Expand Configuration and Management Manual—523347-008
16- 9
Example
Tracing
Table 16-2. Number of Trace Lines Displayed
F Key
Number of Lines
F Key
Number of Lines
F1
1
F9
9
F2
2
F10
10
F3
3
F11
11
F4
4
F12
12
F5
5
F13
13
F6
6
F14
14
F7
7
F15
15
F8
8
F16
16
Example
?NEXT 15 AFTER 13:01
OCTAL Command
The OCTAL command, when set to ON, prints the data portion of a trace record,
including the record header, in octal format.
OCTAL
{ ON | OFF }
ON | OFF
ON enables printing in octal format. OFF disables printing in octal format and
enables printing in hexadecimal format. ON is the default.
Example
?OCTAL ON
OUT Command
The OUT command allows you to direct trace records from your terminal screen to the
spooler or to a line printer.
OUT [ TO file-name ] | STOP
file-name
specifies the name of the spooler or line printer to which you want to direct the
trace records.
Expand Configuration and Management Manual—523347-008
16 -10
Example
Tracing
STOP
closes the spooler or line printer specified in the previous OUT command. As a
result, subsequent trace records are displayed at your terminal.
Example
?OUT $s.#tester
RECORD Command
The RECORD command displays selected records by number. You can select records
individually, in a range, or ALL. If you select records within a range, only records or
record portions that meet the criteria you have defined using the SELECT and FILTER
commands are displayed.
RECORD [ first ] | first,last
| ALL
first
is an integer that specifies the record number of the first, or only, record displayed.
last
is an integer that specifies the record number of the last record to be displayed.
ALL
specifies that all records in the trace file are to be displayed.
Note. The first record in the trace file (the trace file header record) is record number 0. The
first data record is record number 1. A slash (/) can be used in place of a comma. Press the
BREAK key to terminate the display of records.
Examples
The following example displays records numbered 1 through 36:
?RECORD 1/36
The following example displays records numbered 5 through 200:
?RECORD 5,200
Expand Configuration and Management Manual—523347-008
16 -11
SELECT Command
Tracing
SELECT Command
The SELECT command sets the selection criteria for the record types sent to the
output device.
When PTrace is determining which records to display in response to a NEXT, FIND, or
RECORD command, it checks the selection bit mask to determine whether the record
is of a type you want to display. This selection criteria is in addition to the selection
criteria you have set using the FILTER command.
If you do not specify a mask or keyword, ALL bits are set.
SELECT [mask [, mask ] ...] | [ mask [, keyword ] ...]
mask
is an integer that specifies the selection mask directly. The mask can be specified
in decimal, octal, hexadecimal, or binary notation. The hexadecimal and octal
notation is listed in Table 16-3.
keyword
is one of the keywords listed in Table 16-3.
Table 16-3 shows the SELECT options that have meaning when formatting Expand
traces.
Hex Mask
Octal Mask
L0
00
%H80000000
%2000000000
0
L2
02
%H20000000
%0400000000
0
L3
03
%H10000000
%0200000000
0
L4
04
%H08000000
%0100000000
0
PATH
SCF Bit
Line
Keyword
$NCP
Table 16-3. SELECT Options for Expand (page 1 of 2)
X
X
Frames in, direct-connect
X
X
Frames out, direct-connect
X
X
Frames in, satellite-connect
X
X
Frames out, satellite-connect
X
X
Packets sent by $NCP
X
Layer 2 events
X
X
X
Layer 3 events
X
X
X
Description
Layer 4 events
Expand line-handler process
to $NCP messages
X
System ABORT messages
Expand Configuration and Management Manual—523347-008
16 -12
SELECT Command
Tracing
Hex Mask
Octal Mask
$NCP
SCF Bit
PATH
Keyword
Line
Table 16-3. SELECT Options for Expand (page 2 of 2)
X
Description
System CONNECT
messages
X
X
EMS messages
L5
05
%H04000000
%0040000000
0
X
X
Security events
DI
09
%H00800000
%0002000000
0
X
X
Frames in, SWAN
concentrator
X
X
Frames in, IP packets
X
X
Frames out, SWAN
concentrator
X
X
Frames out, IP packets
DO
09
%H00400000
%0002000000
0
CLBI
10
%H00200000
%0001000000
0
X
CLB inbound frames, SWAN
concentrator
CLBO
11
%H00100000
%0000400000
0
X
CLB outbound frames,
SWAN concentrator
CLIPDI
15, 16
%H00018000
%0000030000
0
X
CLIP inbound frames, SWAN
concentrator
CLIPDO
15, 17
%H00014000
%0000024000
0
X
CLIP outbound frames,
SWAN concentrator
CLIPL2
15, 21
%H00010400
%0000202000
0
X
CLIP requests and
responses, CLIP Layer 2
state machine, frames in and
out
ALL
0 to 31
%HFFFFFFF
%3777777777
7
X
CLIP requests and
responses, CLIP Layer 2
state machine, frames in and
out
Expand Configuration and Management Manual—523347-008
16 -13
SELECT Command
Tracing
Expand Configuration and Management Manual—523347-008
16 -14
Part IV. Reference Information
Part IV consists the following sections, which provide reference information:
Section 17
Expand Modifiers
Section 18
Subsystem Description
Expand Configuration and Management Manual—523347-008
Part IV. Reference Information
Expand Configuration and Management Manual—523347-008
17
Expand Modifiers
The Expand subsystem provides many modifiers to allow you to customize your
network. These modifiers are contained in the profiles. Some modifiers are required,
some are optional, some only appear in certain profiles, and others appear in several
profiles.
This section describes the modifiers that are related to the configuration of Expand
line-handler processes. Modifiers that affect the network control process ($NCP) are
discussed in Section 6, Configuring the Network Control Process.
How to Use This Section
The modifiers described in this section are presented in three different ways to meet
your needs:
•
•
•
Required modifiers are listed in Required Modifiers
All the Expand modifiers are listed in alphabetical order in Modifier Dictionary.
Each modifier is described in detail.
Tables listing all the Expand modifiers and the profiles in which they appear are
provided in Profiles.
Required Modifiers
Required modifiers are modifiers that are necessary for successful network operation.
Not all modifiers are required for all types of Expand line-handler processes.
Table 17-1 lists the required modifiers.
Expand Configuration and Management Manual—523347-008
17- 1
Required Modifiers
Expand Modifiers
Table 17-1. Required Modifiers (page 1 of 3)
Modifier
Description
ASSOCIATEDEV
May be used to associate
•
•
•
•
•
The logical device name of a NAM process with an Expandover-NAM line-handler process.
A NonStop TCP/IP process with an Expand-over-IP linehandler process.
An Asynchronous Transfer Mode (ATM) line with an
Expand-over-ATM line-handler process.
The ServerNet monitor process ($ZZSCL) with an Expandover-ServerNet line-handler process.
The FOX monitor process ($ZZFOX) with an Expand-overFOX line-handler process.
Required by: Expand-over-X25, Expand-over-SNA, and
Expand-over-ATM line-handler processes only.
Default: $ZZSCL for Expand-over-ServerNet and $ZZFOX for
Expand-over-FOX line-handler processes. There is no default
value for Expand-over-NAM, Expand-over-IP, and Expand-overATM line-handler processes.
ASSOCIATESUBDEV
Must be used to specify
•
•
•
The name of the X25AM subdevice to which an Expandover-X.25 line-handler process will bind.
The subdevice name of the SNAX/APN logical unit (LU)
used by an Expand-over-SNA line-handler process.
The name of the Asynchronous Transfer Mode (ATM)
service access point (SAP) used by an Expand-over-ATM
line-handler process.
Required by: Expand-over-X25 and Expand-over-SNA, and
Expand-over-ATM line-handler processes only.
Default: There is no default value for Expand-over-NAM linehandler processes; the default value is #IP for Expand-over-ATM
line-handler processes (the only value allowed for Expand-overATM).
ATMSEL
Specifies a hexadecimal selector byte for the ATM line used by
the local Expand-over-ATM line-handler process.
Required by: Expand-over-ATM line-handler processes that use
switched virtual circuit (SVC) connections.
Default: %H80
Expand Configuration and Management Manual—523347-008
17- 2
Required Modifiers
Expand Modifiers
Table 17-1. Required Modifiers (page 2 of 3)
Modifier
Description
CALLTYPE_ATMSAP
Specifies that an ATM protocol direct service access point
(ATMSAP) connection will be used.
Required by: Expand-over-ATM line-handler processes that run
through the SLSA subsystem.
Default: PVC (CALLTYPE_PVC modifier) is the default
connection type.
CALLTYPE_PVC
Specifies that a permanent virtual circuit (PVC) connection will
be used.
Required by: Expand-over-ATM line-handler processes.
Default: PVC is the default connection type.
CALLTYPE_SVC
Specifies that a switched virtual circuit (SVC) connection will be
used.
Required by: Expand-over-ATM line-handler processes.
Default: PVC (CALLTYPE_PVC modifier) is the default
connection type.
DESTATMADDR
Specifies the Asynchronous Transfer Mode (ATM) address
configured for the ATM line used by the Expand-over-ATM linehandler process at the remote system.
Required by: Expand-over-ATM line-handler processes that use
switched virtual circuit (SVC) connections.
Default: 20-byte null address.
DESTIPADDR
Specifies the Internet Protocol (IP) address used by a remote
(destination) Expand-over-IP line-handler process.
Required by: Expand-over-IP line-handler processes if IPVER
is IPv4.
Default: 0.0.0.0.
DESTIPPORT
Specifies the port number used by a remote (destination)
Expand-over-IP line-handler process.
Required by: Expand-over-IP line-handler processes if IPVER
is IPv4.
Default: 1024.
NEXTSYS
Specifies the number of the system connected to the other end
of the line.
Required by: All types of Expand line-handler processes.
Default: 255.*
Expand Configuration and Management Manual—523347-008
17- 3
Required Modifiers
Expand Modifiers
Table 17-1. Required Modifiers (page 3 of 3)
Modifier
Description
PVCNAME
Specifies the name of a permanent virtual circuit (PVC).
Required by: Expand-over-ATM line-handler processes that use
PVC connections.
Default: None
SRCIPADDR
Specifies the Internet Protocol (IP) address associated with a
NonStop TCP/IP process used by a local Expand-over-IP linehandler process.
Required by: Expand-over-IP line-handler processes only.
Default: 0.0.0.0.
SRCIPPORT
Specifies the port number used by a local Expand-over-IP linehandler process.
Required by: Expand-over-IP line-handler processes only.
Default: 1024.
V6DESTIPADDR
Specifies the destination NonStop TCP/IPv6 address used by
the remote Expand-over-IP line-handler process.
Required by: Expand-over-IP line-handler processes if IPVER
is IPv6.
Default: 0000:0000:0000:0000:0000:0000:0000:0000.
V6SRCIPADDR
Specifies the source NonStop TCP/IPv6 address used by the
remote Expand-over-IP line-handler process.
Required by: Expand-over-IP line-handler processes if IPVER
is IPv6.
Default: 0000:0000:0000:0000:0000:0000:0000:0000.
*The default value for this modifier is invalid and must be changed.
Expand Configuration and Management Manual—523347-008
17- 4
Modifier Dictionary
Expand Modifiers
Modifier Dictionary
This subsection lists in alphabetical order all the modifiers used to configure Expand
line-handler processes and describes each modifier in detail. Default values and value
ranges are described, if applicable.
AFTERMAXRETRIES_DOWN/
AFTERMAXRETRIES_PASSIVE
Default:
Units:
Range:
AFTERMAXRETRIES_DOWN
Not applicable
Not applicable
These modifiers are applicable to Expand-over-NAM, Expand-over-IP, Expand-overATM, Expand-over-ServerNet, and Expand-over-FOX line-handler processes only.
The AFTERMAXRETRIES_DOWN modifier causes the Expand line-handler process to
go to the DOWN state once the maximum number of retries (as specified by the
MAXRECONNECTS modifier) has been exhausted.
The AFTERMAXRETRIES_PASSIVE modifier causes the Expand line-handler process
to switch to passive connect mode once the maximum number of retries (as specified
by the MAXRECONNECTS modifier) has been exhausted. For Expand-over-NAM,
Expand-over-ServerNet, and Expand-over-FOX line-handler processes, if the
AFTERMAXRETRIES_PASSIVE modifier is specified together with the
CONNECTTYPE_PASSIVE modifier, the AFTERMAXRETRIES_PASSIVE modifier will
override the connect-type modifier, changing the connect mode to active.
ASSOCIATEDEV $dev-name
Default:
Units:
Range:
$ZZSCL for Expand-over-ServerNet line-handler processes
$ZZFOX for Expand-over-FOX line-handler processes
None for Expand-over-IP line-handler processes
None for Expand-over-ATM line-handler processes
None for Expand-over-NAM line-handler processes
Not applicable
Any eight-character string
This modifier is used for Expand-over-NAM, Expand-over-IP, Expand-over-ATM,
Expand-over-ServerNet, and Expand-over-FOX line-handler processes only. This
modifier associates the logical device name of an X25AM or SNAX/APN line-handler
process with an Expand-over-X.25 or Expand-over-SNA line-handler process. This
modifier is also used to associate a NonStop TCP/IP process with an Expand-over-IP
line-handler process, an ATM line with an Expand-over-ATM line-handler process, the
$ZZSCL process with an Expand-over-ServerNet line-handler process, and the
$ZZFOX process with an Expand-over-FOX line-handler process.
Expand Configuration and Management Manual—523347-008
17- 5
ASSOCIATESUBDEV #n
Expand Modifiers
ASSOCIATESUBDEV #n
Default:
Units:
Range:
No default for Expand-over-NAM line-handler processes
#IP for Expand-over-ATM line-handler processes
Not applicable
Not applicable
This modifier is required for Expand-over-NAM and Expand-over-ATM line-handler
processes only. n may specify the following:
•
•
•
The name of an X25AM subdevice to which the Expand-over-X.25 line-handler
process will bind.
The subdevice name of the SNAX/APN logical unit (LU) used by the Expand-overSNA line-handler process.
The name of the Asynchronous Transfer Mode (ATM) service access point (SAP)
used by the Expand-over-ATM line-handler process. The only currently supported
SAP is #IP.
ATMSEL n
Default:
Units:
Range:
%H80
Not applicable
0 through %HFF
This modifier is applicable to Expand-over-ATM line-handler processes that use
switched virtual circuits (SVCs) only. It specifies a hexadecimal selector byte for the
ATM line used by the local Expand-over-ATM line-handler process. The selector byte is
used by the ATM subsystem to direct incoming call requests to the correct ATM
subsystem client. Selector bytes must be coordinated among ATM clients using the
same ATM line. The selector byte is the last (rightmost) byte in an ATM address.
CALLTYPE_PVC/CALLTYPE_SVC/CALLTYPE_ATMSAP
Default:
Units:
Range:
CALLTYPE_PVC
Not applicable
Not applicable
These modifiers are applicable to Expand-over-ATM line-handler processes only. The
CALLTYPE_PVC modifier indicates that a permanent virtual circuit (PVC) connection
will be used. The CALLTYPE_SVC modifier indicates that a switched virtual circuit
(SVC) connection will be used. The CALLTYPE_ATMSAP modifier indicates that the
ATMSAP connection through the SLSA subsystem will be used.
Expand Configuration and Management Manual—523347-008
17- 6
CLOCKMODE_DCE/CLOCKMODE_DTE
Expand Modifiers
CLOCKMODE_DCE/CLOCKMODE_DTE
Default:
Units:
Range:
CLOCKMODE_DCE
Not applicable
Not applicable
These modifiers are applicable to direct-connect and satellite-connect Expand linehandler processes only. The CLOCKMODE_DCE modifier disables the
communications line interface processor (CLIP) clock on the ServerNet wide area
network (SWAN) concentrator used by the line. It causes the SWAN concentrator to
provide no clocking. The CLOCKMODE_DTE modifier enables the communications
line processor (CLIP) clock. This modifier enables the internally generated clock when
it is used in conjunction with the CLOCK modifier.
CLOCKSPEED_600/CLOCKSPEED_1200
CLOCKSPEED_2400/CLOCKSPEED_4800
CLOCKSPEED_9600/CLOCKSPEED_19200
CLOCKSPEED_38400/CLOCKSPEED_56000
CLOCKSPEED_115200
Default:
Units:
Range:
CLOCKSPEED_19200
Kilobits per second (Kbps)
Not applicable
These modifiers are applicable to direct-connect and satellite-connect Expand linehandler processes only. These modifiers override the default speed of the internally
generated communications line interface processor (CLIP) on the ServerNet wide area
network (SWAN) concentrator. The CLOCKMODE_DTE modifier must also be
specified to enable the internal clock.
COMPRESS_OFF/COMPRESS_ON
Default:
Units:
Range:
COMPRESS_ON
Not applicable
Not applicable
These path modifiers are applicable to all Expand line types. The COMPRESS_ON
modifier specifies that data compression will be performed. Data compression causes
multiple blanks, zeros, and nulls to be removed before data transmission. You can stop
data compression from being performed by using the COMPRESS_OFF modifier.
You can increase the net line throughput by using the COMPRESS_ON modifier
because compression causes the number of bytes transmitted to be reduced; however,
if data being transmitted is not compressible and the COMPRESS_ON modifier is
used, throughput can actually be reduced (processor cycles are required to perform
compression).
Expand Configuration and Management Manual—523347-008
17- 7
CONNECTTYPE_ACTIVEANDPASSIVE/
CONNECTTYPE_PASSIVE
Expand Modifiers
To determine if data compression should be set, you should examine the message
traffic character composition to assess its compressibility. For example, EDIT files do
not compress well, while structured files and object code compress an average of 20 to
50 percent.
If compressed data is received by an Expand line-handler process that does not have
compression configured, the data will still be decompressed. Therefore, it is not
mandatory that the COMPRESS_ON modifier be configured at both ends of a line.
In a FOX ring, compression does not occur for traffic passing directly from one cluster
to another within the same ring.
CONNECTTYPE_ACTIVEANDPASSIVE/
CONNECTTYPE_PASSIVE
Default:
Units:
Range:
CONNECTTYPE_ACTIVEANDPASSIVE
Not applicable
ON or OFF
These modifiers are applicable to Expand-over-NAM, Expand-over-IP, Expand-overATM, Expand-over-ServerNet, and Expand-over-FOX line-handler processes.
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, the CONNECTTYPE_ACTIVEANDPASSIVE modifier indicates to the
network access method (NAM) that it should first issue call requests and then, if the
requests are unsuccessful, then wait for an incoming call request.
For Expand-over-IP and Expand-over-ATM line-handler processes, the
CONNECTTYPE_ACTIVEANDPASSIVE modifier indicates that the Expand-over-IP or
Expand-over-ATM line-handler process sends a Connect request; if the Connect
request is unsuccessful, then the Expand-over-IP or Expand-over-ATM line-handler
process waits for an incoming Connect request.
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, the CONNECTTYPE_PASSIVE modifier causes the network access
method (NAM) to wait for incoming connect requests; the NAM will not initiate connect
requests.
For Expand-over-IP and Expand-over-ATM line-handler processes, the
CONNECTTYPE_PASSIVE modifier indicates that the Expand-over-IP or Expandover-ATM line-handler process will wait for incoming call requests; it will not initiate
connect requests.
If specified with AFTERMAXRETRIES_PASSIVE, the CONNECTTYPE_PASSIVE
modifier will revert to active connect mode. To get the line up in passive connect mode,
add the AFTERMAXRETRIES_DOWN modifier.
Expand Configuration and Management Manual—523347-008
17- 8
DELAY n
Expand Modifiers
DELAY n
Default:
Units:
Range:
10 (0.10 second)
Milliseconds
0 through 511 (0 to 5.11 seconds)
This Layer 2 modifier is applicable to direct-connect Expand line-handler processes
only. This modifier sets the amount of time, in one-hundredth of a second increments,
that a data bit spends on the line during message transmission. The Expand linehandler process uses the transmission size, the amount of delay before the message
can be dispatched, and the DELAY modifier value to select the most efficient line for
data transmission within a path that consists of multiple lines.
Transmission delay is usually minimal on a terrestrial link. Transmission delay on a
satellite link is greater than on a terrestrial link.
DESTATMADDR n
Default:
Units:
Range:
(ISONSAP:%H0000000000000000000000000000000000000000)
Not applicable
Any valid ISO NSAP ATM address
This modifier is applicable to Expand-over-ATM line-handler processes that use
switched virtual circuits (SVCs). This modifier specifies the Asynchronous Transfer
Mode (ATM) address configured for the ATM line used by the Expand-over-ATM linehandler process at the destination system.
The address must be specified by number in the form (ISONSAP:%Hatm-address)
where atm-address is the 20-byte ATM address.
DESTIPADDR n
Default:
Units:
Range:
0.0.0.1
Not applicable
Any 36-character string
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the Internet Protocol (IP) address used by the remote (destination) Expandover-IP line-handler process. It is the IP address specified in the remote line-handler
process’ SRCIPADDR modifier.
The address must be specified by number (for example, 130.252.12.3). It is not
validated and need not be accessible. Configuring IP addresses is explained in the
TCP/IP Configuration and Management Manual.
Expand Configuration and Management Manual—523347-008
17- 9
DESTIPPORT n
Expand Modifiers
DESTIPPORT n
Default:
Units:
Range:
1024
Not applicable
0 through 65534
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the port number used by the remote (destination) Expand-over-IP linehandler process. It is the port number specified in the remote line-handler process’
SRCIPPORT modifier. Port numbers are explained in the TCP/IP Configuration and
Management Manual.
DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF
Default:
Units:
Range:
OFF
Not applicable
Not applicable
If set ON and the QUALITYTIMER timer expires, an EMS message is generated and
the line is aborted (see the QUALITYTIMER n and QUALITYTHRESHOLD n
parameters). If set OFF and the QUALITYTIMER timer expires, an EMS message is
generated and the line is not aborted.
This modifier is applicable to both single-line and multi-line IP, ATM, satellite, and
SWAN line-handler processes.
EXTMEMSIZE n
Default:
Units:
Range:
2048 kbytes (2 megabytes)
kbytes
0 through 32767 kbytes (32 megabytes)
This modifier allows you to specify the base size of extended memory for Expand’s
internal buffer pool.
FLAGFILL_OFF/ FLAGFILL_ON
Default:
Units:
Range:
FLAGFILL_ON
Not applicable
ON or OFF
These Layer 2 modifiers are applicable to direct-connect and satellite-connect Expand
line-handler processes only. The FLAGFILL_ON modifier causes a specific bit pattern
called FLAG to be set during the idle period for a line. You can use the FLAGFILL_OFF
modifier to cause bit-synchronous controllers to keep an idle line in the MARK HOLD
instead of the IDLE FLAGS state. Some modems and data circuit-terminating
equipment (DCE) require the idle line state to be configured with the FLAGFILL_ON
modifier.
Expand Configuration and Management Manual—523347-008
17 -10
FRAMESIZE n
Expand Modifiers
FRAMESIZE n
Default:
Units:
Range:
132
Words
64 through 2047
This Layer 2 modifier is applicable to all Expand line types. This modifier specifies the
maximum size frame that can be sent in the network; smaller frames may be sent. The
FRAMESIZE modifier is also used by the Expand subsystem to calculate the packet
size, which determines the size of the frame buffers.
The Expand subsystem calculates the packet size (in words) using the following
formula:
packet_size = FRAMESIZE - 4
If the default FRAMESIZE modifier value is used, the packet size is 128 words. The
FRAMESIZE modifier, packet size, and frame buffers are described in Section 18,
Subsystem Description.
Note. The line-handler FRAMESIZE value must be the same for every Expand line-handler
process on every node in the network. However, the FRAMESIZE modifier value specified for
the network control process ($NCP) must be equal to or less than the line-handler
FRAMESIZE, but it does not have to be the same on all nodes in the network.
INTERFACE_RS232/INTERFACE_RS422
Default:
Units:
Range:
INTERFACE_RS232
Not applicable
ON or OFF
These communications hardware modifiers are applicable to direct-connect and
satellite-connect line-handler processes only. The INTERFACE_RS232 modifier
specifies that RS-232 is the type of modem connected to the interface. The
INTERFACE_RS422 modifier specifies that RS-422 is the type of modem connected to
the interface.
IPVER_IPV4/IPVER_IPV6
Default:
Units:
Range:
IPv4
Not applicable
Not applicable
This modifier specifies whether to create an IPv4 or an IPv6 socket. If IPv4, the
ASSOCIATEDEV parameter can refer to any NonStop TCP/IP product and the
SRCIPADDR and DESTIPADDR modifiers are used for the local and remote IP
addresses. If IPv6, the ASSOCIATEDEV parameter must refer to NonStop TCP/IPv6
and the V6SRCIPADDR and V6DESTIPADDR modifiers are used for the local and
remote IP addresses.
Expand Configuration and Management Manual—523347-008
17 -11
L2DISCARDONRESET_OFF/L2DISCARDONRESE
T_ON
Expand Modifiers
L2DISCARDONRESET_OFF/L2DISCARDONRESET_ON
Default:
Units:
Range:
L2DISCARDONRESET_ON
Not applicable
ON or OFF
These Layer 2 modifiers are applicable to direct-connect and satellite-connect linehandler processes only. The L2DISCARDONRESET_ON modifier causes
unacknowledged High-Level Data Link Control (HDLC) frames to be discarded at the
transmitting node and causes recovery to take place at Layer 4 when either the
transmitting or the receiving node initiates a link reset (SABM-UA exchange).
The L2DISCARDONRESET_ON modifier should be enabled on direct-connect and
satellite-connect lines in paths that contain multiple high-speed lines that are prone to
outages or significant variances in transmission delay.
L2RETRIES n
Default:
Units:
Range:
20 for Expand-over-IP and Expand-over-ATM
10 for all other line types
Not applicable
1 through 255
This Layer 2 modifier is applicable to all Expand line types. This modifier specifies the
number of times that the Expand line-handler process will retry a request at Layer 2
before reporting an error. A minimum value of 3 is recommended for the L2RETRIES
modifier.
The purpose of the L2RETRIES modifier is to bridge common failures without
unnecessarily rerouting traffic. A correct value for the L2RETRIES modifier depends on
a thorough knowledge of the network and the application. In general, the L2RETRIES
modifier should be selected so that the result of the following algorithm is greater than
the characteristic short-term failure mode of the network and 15 seconds less than the
delay tolerance of the application:
L2RETRIES * L2TIMEOUT * 3
The result of this algorithm is the point at which the Expand line-handler process will
declare the line unusable and begin rerouting. For most networks the result will be a
value that allows you to bridge 10-second to 30-second network outages.
Note. The L2TIMEOUT modifier is the time interval that the Expand line-handler process will
wait for a response to a request at Layer 2 before retrying. You can modify the Layer 2 timeout
using the L2TIMEOUT modifier.
Expand Configuration and Management Manual—523347-008
17 -12
L2TIMEOUT n
Expand Modifiers
L2TIMEOUT n
Default:
Units:
Range:
100 (1.00 second) for direct-connect lines
200 (2.00 seconds) for satellite-connect lines
0.01 seconds
20 through 32767
This Layer 2 modifier is applicable to direct-connect and satellite-connect line-handler
processes only. This modifier specifies the length of time, in one-hundredth of a
second increments, that the Expand line-handler process will wait for a response to a
request at Layer 2 before retrying. (The number of retries is determined by the
L2RETRIES modifier.)
You can calculate the value of the L2TIMEOUT modifier using the following algorithm:
((txw + 1) * fsz * 16) / (lspd / 100)) + (2 * dl) + 10
where txw is the TXWINDOW modifier value, fsz is the FRAMESIZE modifier value,
lspd is the line speed in bits per second (actual, not configured), and dl is the DELAY
modifier value. The result of this algorithm should be the worst-case possible delay for
a successful transmission. However, you should keep in mind that a limit less than 0.5
seconds can be affected by vendor rerouting over alternate facilities, and a limit greater
than 0.5 seconds can seriously affect recovery times in case of actual failure.
When the multipacket frame feature or variable packet size feature is used, the value
specified for the L2TIMEOUT modifier should be based on the transmission time
required for the larger configured PATHBLOCKBYTES or PATHPACKETBYTES
modifier value rather than on the configured FRAMESIZE modifier value.
When the multipacket frame feature is used, you can calculate the value of the
L2TIMEOUT modifier using the following algorithm:
(((txw + 1) * pathblockbytes * 8) / (lspd / 100)) + (2 * dl) + 10
When the variable packet size feature is used, you can calculate the value of the
L2TIMEOUT modifier using the following algorithm:
(((txw + 1) * pathpacketbytes * 8) / (lspd / 100)) + (2 * dl) + 10
The result of these algorithms is a one-hundredth of a second value.
Note. If you use the Expand subsystem SCF ALTER LINE command to set the L2TIMEOUT
modifier, you must convert the result of this algorithm to a time interval. For example, if the
result was 300 (3 seconds), you would enter the following command:
ALTER LINE $device_name, L2TIMEOUT 3.00.
For more information about the multipacket frame and variable packet size features,
refer to Section 18, Subsystem Description.
Expand Configuration and Management Manual—523347-008
17 -13
L4CONGCTRL_OFF/L4CONGCTRL_ON
Expand Modifiers
L4CONGCTRL_OFF/L4CONGCTRL_ON
Default:
Units:
Range:
L4CONGCTRL_ON for Expand-over-IP and Expand-over-ATM lines
L4CONGCTRL_OFF for other line types and multi-line paths
Not applicable
ON or OFF
These path modifiers are applicable to all Expand line types. The L4CONGCTRL_ON
modifier enables the congestion control mechanism on the Expand node for sending
packets on a path. Congestion control mechanisms regulate system resources in order
to avoid network bottleneck and resource contention situations.
L4CONGCTRL is a path parameter and the path profile sets L4CONGCTRL_OFF
because it is shared by all line types. Therefore, multi-line IP paths default to
L4CONGCTRL_OFF and must specify L4CONGCTRL_ON.
The L4CONGCTRL_ON modifier is also recommended for Expand line-handler
processes that are part of a multi-CPU path.
You should read the description of the congestion control feature in Section 18,
Subsystem Description, before using this modifier.
L4EXTPACKETS_OFF/L4EXTPACKETS_ON
Default:
Units:
Range:
L4EXTPACKETS_ON
Not applicable
ON or OFF
These path modifiers are applicable to all Expand line types. The
L4EXTPACKETS_ON modifier enables an extended packet header format of 64 bytes
for all lines in a path. The extended packet header format allows increased throughput
over high bandwidth and multi-line paths.
The L4EXTPACKETS_ON modifier is required for the variable packet size and
congestion control features and for Expand line-handler processes that are part of a
multi-CPU path. The L4EXTPACKETS_ON modifier is also required to support the
larger message size of 60K bytes. If the modifier is not set ON, the message size will
be 32K bytes.
The L4EXTPACKETS_OFF modifier specifies that the older 16-byte packet header
format should be used. It can be used to provide performance compatibility with lowerspeed lines.
L4RETRIES n
Default:
Units:
Range:
3
Not applicable
3 through 255
This path modifier is applicable to all Expand line types. This modifier specifies the
number of times that the Expand line-handler process will try an end-to-end (Layer 4)
Expand Configuration and Management Manual—523347-008
17 -14
L4SENDWINDOW n
Expand Modifiers
request before reporting an error. You should read the description of Layer 4 retries in
Section 18, Subsystem Description, before using this modifier.
Note. The L4RETRIES modifier value should be set to the same value for every Expand linehandler process on every node in the network.
L4SENDWINDOW n
Default:
Units:
Range:
254
Packets
187 through 254
This path modifier is applicable to all Expand line types. This modifier specifies the
size, in packets, of the Layer 4 send window. This window determines how many
packets are sent before an acknowledgment is required. The default value allows up to
254 unacknowledged packets in any single end-to-end (Layer 4) connection.
The L4SENDWINDOW modifier value should be reduced from the default of 254 for
paths that consist of multiple lines of greatly varying speeds. Using the default value in
this type of configuration can result in the retransmission of many packets during errorrecovery and can increase out-of-sequence (OOS) packet processing.
For example, if a path has two lines, one at a speed of 224 Kbps and the other at a
speed of 19.2 Kbps, setting the L4SENDWINDOW modifier to its lower limit of 187 will
help ensure that packets traveling on the faster line are not discarded because they
are too far ahead of packets traveling on the slower line.
L4TIMEOUT n
Default:
Units:
Range:
2000 (20.00 seconds)
0.01 seconds
50 through 32767 (0.5 seconds through 5:27.67 minutes)
This path modifier is applicable to all Expand line types. This modifier specifies the
time interval, in one-hundredth of a second increments, that the Expand line-handler
process will wait for a response to an end-to-end (Layer 4) request before retrying. You
should read the description of the Layer 4 timeout in Section 18, Subsystem
Description, before using this modifier.
The Layer 4 timeout should not expire until all Layer 2 activity related to a specific
message transmission has ceased. Therefore, the L4TIMEOUT modifier value should
be large enough to span the worst case (the sum of the intermediate Layer 2 timers for
the longest end-to-end route).
The following algorithm can be used to determine the L4TIMEOUT value:
L4TIMEOUT = (((l2retries * l2timeout * 3) + 10) * q)
l2retries is the number of times that the Expand line-handler process will try a
request at Layer 2 before reporting an error. (You can modify this value using the
L2RETRIES modifier as described in L2RETRIES n on page 17-12.)
Expand Configuration and Management Manual—523347-008
17 -15
LIFNAME n
Expand Modifiers
l2timeout is the time interval, in one-hundredth of a second increments, that the
Expand line-handler process will wait for a response to a request at Layer 2 before
retrying. (You can modify this value using the L2TIMEOUT modifier as described
L2TIMEOUT n on page 17-13.)
q is the hop count (HC) of the longest end-to-end route in the network.
For Expand-over-X.25 connections, you should set the L4TIMEOUT modifier to a value
larger than the maximum anticipated response time on a loaded link.
Note. The L4TIMEOUT modifier should be set to the same value for every Expand linehandler process on every node in the network.
LIFNAME n
Default:
Units:
Range:
None
Not applicable
Not applicable
This modifier is applicable to Expand-over-ATM line-handler processes that use the
ATMSAP connection through the SLSA subsystem. This modifier identifies the name of
the logical interface by which LAN access is known to the system. Only the name
portion of the LIF name should be specified (for example, LIF01).
LINEPRIORITY n
Default:
Units:
Range:
1
Integers
1 through 9
This modifier is applicable to all multi-line types. It can be set in the range 1 to 9. The
default is 1. The higher the number, the lower priority to use that line. If lines have
equal priority, the relative line speeds and transmission delays are used to select the
next line.
LINETF n
Default:
Units:
Range:
0 (unset)
Not applicable
0 through 186
The LINETF modifier has a range of 0 to 186 to designate the line time factor in
selecting the best path to other nodes in the network. A smaller number indicates a
more desirable path for routing. If you set the LineTF, it overrides the RSIZE, SPEED,
or SPEEDK parameters in calculating the time factor for the line (PathTF overrides all
parameters, including LINETF).
If LINETF is left unset (a zero value), this parameter is not used in setting the time
factor. Either RSIZE, SPEED, SPEEDK, LINETF, or PATHTF must be set, else the line
Expand Configuration and Management Manual—523347-008
17 -16
MAXRECONNECTS n
Expand Modifiers
handler will display a configuration error. Refer to Setting Time Factors on page 18-23
for more detailed information about establishing time factors.
MAXRECONNECTS n
Default:
Units:
Range:
0
Not applicable
0 through 32767
This modifier is applicable to Expand-over-NAM, Expand-over-IP, Expand-over-ATM,
Expand-over-ServerNet, and Expand-over-FOX line-handler processes.
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, this modifier specifies the maximum number of times the Expand linehandler process will try a connect request after successfully binding to the network
access method (NAM) interface.
For Expand-over-IP and Expand-over-ATM line-handler processes, this modifier
specifies the maximum number of times the Expand-over-IP or Expand-over-ATM linehandler process will try to connect to the remote Expand-over-IP or Expand-over-ATM
line-handler process. A value of 0 indicates an infinite number of retries.
NEXTSYS n
Default:
Units:
Range:
255
Not applicable
0 through 254
This path modifier is applicable to all Expand line types. This modifier specifies the
number of the system connected to the other end of the line. If you do not specify the
NEXTSYS modifier, it defaults to an invalid value (255), and an operator message
occurs during the initialization of this Expand line-handler process. The path will not be
operational until you alter the NEXTSYS modifier to a valid value using either the WAN
subsystem SCF ALTER DEVICE command or the Expand subsystem SCF ALTER
PATH command.
OSSPACE n
Default:
Units:
Range:
32767
Words
3072 through 32767
This path modifier is applicable to all Expand line types. This modifier defines the
maximum buffer size for storing out-of-sequence (OOS) packets, in words. The OOS
buffer is in the data segment or the extended data segment. Networks that include
Expand Configuration and Management Manual—523347-008
17 -17
OSTIMEOUT n
Expand Modifiers
multi-line paths may require all Expand line-handler processes to have more than the
default buffer size for storing OOS packets.
Note. The OSSPACE modifier is currently ignored. The amount of space allocated to out-ofsequence (OOS) packets is limited by the OSTIMEOUT modifier and by the base size of the
line handler’s data segment. The OSSPACE modifier may be used in the future, in which case
its default, units, and range may be different. For this reason, the recommended setting for
OSSPACE is to not specify it, but to let the default be used.
OSTIMEOUT n
Default:
Units:
Range:
300 (3 seconds)
0.01 seconds
10 through 32767 (0.1 seconds through 5:27.67 minutes)
This path modifier is applicable to all Expand line types. This modifier specifies the
amount of time, in one-hundredth of a second increments, that out-of-sequence (OOS)
packets are held before they are discarded. For example, an OSTIMEOUT modifier
value of 300 is equal to 3 seconds. In general, the OSTIMEOUT modifier value should
be greater than the L2TIMEOUT modifier value and less than the L4TIMEOUT modifier
value.
The OSTIMEOUT modifier must be set to the same value for every Expand linehandler process on every node in the network. If congestion control is enabled for any
system in the network, an OSTIMEOUT modifier value of at least 3 seconds is
recommended.
PATHBLOCKBYTES n
Default:
Units:
Range:
0
Bytes
0 or 1024 through 9180 for Expand-over-ATM and Expand-over-IP lines
0 or 1024 through 4095 for all other Expand line types
This path modifier is applicable to all Expand line types. This modifier specifies the
maximum size, in bytes, of a multipacket frame. You should read the description of the
multipacket frame feature in Section 18, Subsystem Description, before using this
modifier.
The value of n must be larger than the result of the following equation:
n > framesize * 4
where framesize is the configured frame size, in words, as specified by the
FRAMESIZE modifier. If n is not greater than the result of this equation, the
PATHBLOCKBYTES modifier will be set to zero, the multipacket frame feature will be
permanently disabled, and an operator message will be logged.
If both the PATHBLOCKBYTES and PATHPACKETBYTES modifiers are enabled, the
PATHBLOCKBYTES modifier value must be greater than or equal to the
PATHPACKETBYTES modifier value. If the PATHBLOCKBYTES modifier value is less
Expand Configuration and Management Manual—523347-008
17 -18
PATHPACKETBYTES n
Expand Modifiers
than the PATHPACKETBYTES modifier value, the PATHBLOCKBYTES modifier value
is automatically changed to the PATHPACKETBYTES modifier value.
A value of 0 (the default) specifies that the multipacket frame feature will be disabled.
A value of 0 is recommended for Expand-over-ATM lines.
PATHPACKETBYTES n
Default:
Units:
Range:
1024
Bytes
0 or 1024 through 9180 for Expand-over-ATM and Expand-over-IP lines
0 or 1024 through 4095 for all other Expand line types
This path modifier is applicable to all Expand line types. This modifier specifies the
maximum size, in bytes, of a variable packet. You should read the description of the
variable packet size feature in Section 18, Subsystem Description, before using this
modifier.
The variable packet size feature cannot be used if the FRAMESIZE modifier is 517 or
more words. This feature does not provide any benefit on paths configured with the
L4EXTPACKETS_OFF modifier, which specifies that the extended 64-byte packet
header format not be used. Nonextended frames are not fragmentable and therefore
must use the network-wide FRAMESIZE modifier value.
The value of n must be larger than the result of the following equation:
n > framesize * 4
where framesize is the configured frame size, in words, as specified by the
FRAMESIZE modifier. If n is not greater than the result of this equation,
PATHPACKETBYTES will be set to zero, the variable packet size feature will be
permanently disabled, and an operator message will be logged.
To enable the PATHPACKETBYTES modifier, the setting must be greater than or equal
to 1024. If the PATHPACKETBYTES modifier was set to a value less than 1024, but
greater than 0, it is automatically changed to 1024.
If both the PATHBLOCKBYTES and PATHPACKETBYTES modifiers are enabled, the
PATHBLOCKBYTES modifier must be greater than or equal to the
PATHPACKETBYTES modifier value. If the PATHBLOCKBYTES modifier value is less
than the PATHPACKETBYTES modifier value, the PATHBLOCKBYTES modifier value
automatically changes to the PATHPACKETBYTES modifier value.
A value of 0 specifies that the variable packet size feature will be disabled.
A value of 9152 is recommended for Expand-over-ATM lines.
Expand Configuration and Management Manual—523347-008
17 -19
PATHTF n
Expand Modifiers
PATHTF n
Default:
Units:
Range:
0 (unset)
Not applicable
0 through 186
The PATHTF has a range of 0 to 186 to designate the time factor in selecting the best
path to other nodes. A smaller number indicates a more desirable path for routing. If
you set PATHTF, it overrides any other parameter (RSIZE, SPEED, SPEEDK, or
LINETF) in calculating the time factor for the path.
When PATHTF is set for a multi-line path, the line state and number of lines in the path
are ignored and the PATHTF setting is a constant value assigned to the time factor for
the path.
If PATHTF is left unset (a zero value), this parameter is not used in setting the time
factor. Either RSIZE, SPEED, SPEEDK, LINETF, or PATHTF must be set, else the line
handler will display a configuration error. Refer to Setting Time Factors on page 18-23
for more detailed information on establishing time factors.
PROGRAM n
Default:
Units:
Range:
$SYSTEM.CSSnn.C1097P00 for direct-connect lines
$SYSTEM.CSSnn.C1098P00 for satellite-connect lines
Not applicable
Not applicable
This modifier is applicable to direct-connect and satellite-connect Expand line-handler
processes only. This modifier identifies the specific microcode file where the data link
control (DLC) task is located. The microcode file is downloaded to the ServerNet wide
area network (SWAN) concentrator communications line interface processor (CLIP)
when the line is started. For more information about DLC tasks, see the WAN
Subsystem Configuration and Management Manual.
PVCNAME n
Default:
Units:
Range:
None
Not applicable
Not applicable
This modifier is applicable to Expand-over-ATM line-handler processes that used
permanent virtual circuit (PVC) connections. This modifier identifies the name of the
PVC used by the Expand-over-ATM line-handler process. Only the name portion of the
PVC name should be specified (for example, PVC01).
Expand Configuration and Management Manual—523347-008
17 -20
QUALITYTHRESHOLD n
Expand Modifiers
QUALITYTHRESHOLD n
Default:
Units:
Range:
0
Integers
0 through 99
If the line reports quality lower than this percentage value, a timer is started. See also
DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF and QUALITYTIMER n.
This modifier is applicable to both single-line and multi-line IP, ATM, satellite, and
SWAN line-handler processes.
QUALITYTIMER n
Default:
Units:
Range:
0
hh:mm:ss
0 through 12 hours
This modifier specifies the time interval to wait after the line quality drops below the
threshold value specified in the QUALITYTHRESHOLD before taking the action
specified in the parameter DOWNIFBADQUALITY. See also QUALITYTHRESHOLD n
and DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF.
This modifier is applicable to both single-line and multi-line IP, ATM, satellite, and
SWAN line-handler processes.
RETRYPROBE n
Default:
Units:
Range:
19 for IP and ATM lines
10 for Expand-over-FOX and Expand-over-ServerNet lines
20 for Expand-over-NAM lines
seconds
1 through 255
This modifier specifies the number of times the Expand-over-NAM, Expand-overServerNet, or Expand-over-FOX line-handler process will retry its probe of the network
access method (NAM), or how many times the Expand-over-IP or Expand-over-ATM
line-handler process will retry the probe of the remote Expand-over-IP or Expand-overATM line-handler process before declaring the network unavailable. A value of 0
indicates that timeouts are ignored and the connect state is maintained. See also
TIMERPROBE n and TIMERRECONNECT n.
Expand Configuration and Management Manual—523347-008
17 -21
RSIZE n
Expand Modifiers
RSIZE n
Default: None
Units: Not applicable
Range: 0 through 186
This required modifier specifies the time factor of the line for the Expand routing
algorithm. RSIZE must always be set to 1 for $NCP and set to 0 for the path device of
a multi-line path.
Starting with G06.20, you can use the new parameters, LINETF n and PATHTF n, to
set values for lines that will override all other parameters in calculating time factors.
Either RSIZE, SPEED, SPEEDK, LINETF, or PATHTF must be set or the line handler
will display a configuration error. If LINETF, PATHTF, SPEED, or SPEEDK are set, any
RSIZE value is ignored.
To change the line time factor with the ALTER LINE command, use the LINETF
modifier. Refer to Setting Time Factors on page 18-23 for more detailed information
about establishing time factors.
RXWINDOW n
Default:
Units:
Range:
7
Packets
2 through 15 for all line types
This modifier is applicable to all Expand line types.
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, this modifier specifies the number of packets that the network access
method (NAM) process can send to the Expand line-handler process before requiring
acknowledgment.
For Expand-over-IP and Expand-over-ATM line-handler processes, this modifier is
meaningless but is kept for commonality between the line types. For example, because
an Expand-over-IP line-handler processes uses QIO to communicate with its
associated NonStop TCP/IP process, the Expand-over-IP line-handler process must
read all the messages on its receive queue at one time; it cannot limit the number of
messages read to the RXWINDOW modifier value because of QIO limitations.
SPEED n
Default:
Units:
Range:
0
bits per second (bps)
0 or 1200 through 224000
This modifier provides a way of creating the time factor, and has a maximum value of
224,000. Its use is no longer recommended.
Starting with G06.20, you can use the new parameters, LINETF n and PATHTF n, to
set time factors for lines that will override all other parameters in calculating time
Expand Configuration and Management Manual—523347-008
17 -22
SPEEDK n
Expand Modifiers
factors. PATHTF overrides RSIZE, SPEED, SPEEDK, or LINETF, whereas LINETF
overrides RSIZE, SPEED, and SPEEDK (but not PATHTF). Either RSIZE, SPEED,
SPEEDK, LINETF, or PATHTF must be set, else the line handler will display a
configuration error.
The formula to convert from SPEED to LINETF is:
LINETF = (224000 + (SPEED / 2)) / SPEED
Refer to Setting Time Factors on page 18-23 for more detailed information about
establishing time factors.
SPEEDK n
Default:
Units:
Range:
none. (The value NOT_SET is displayed)
Kbps as integers, integers with K or M suffixes, or symbolic names
1 through 4,000,000,000 and symbolic values shown in table below
This modifier, introduced in G06.08 but not recommended as of G06.20, specifies the
line speed in Kbps.
Either RSIZE, SPEED, SPEEDK, LINETF, or PATHTF must be set, else the line
handler will display a configuration error.
You can specify SPEEDK values in Kbps or use symbolic names for line types that
have fixed speeds. The available names are listed in Table 17-2.
Here are the rules for converting SPEEDK to a time factor:
if SPEEDK >= FOX (21000) then the time factor = 1
For SPEEDK values less than FOX (21000) the time factor will be based on the
formula:
TF = Round( (4000000000 / SpeedK ) / 190000)
where the remainder is rounded up if it is .7 or larger.
This calculation will give a time factor of 1 for all lines which have a SPEEDK of FOX or
faster. If old profiles are used, a ServerNet line, ATM line, and a FOX line would all
have the same time factor of 1. This calculation will also limit the maximum time factor
to 186.
Starting with G06.20, you can use the new parameters, LINETF n and PATHTF n, to
set time factors for lines that will override all other parameters in calculating time
factors. PATHTF overrides RSIZE, SPEED, SPEEDK, or LINETF, whereas LINETF
overrides RSIZE, SPEED, and SPEEDK (but not PATHTF). Refer to Setting Time
Factors on page 18-23 for more detailed information on establishing time factors.
Table 17-2 shows the time-factor conversions for various SPEEDK settings:
Expand Configuration and Management Manual—523347-008
17 -23
SPEEDK n
Expand Modifiers
Table 17-2. Time Factor and SPEEDK Conversions
SPEEDK
Time Factor
Symbol
9
186
19
186
48
186
56
186
64
186
128
164
224
94
256
82
500
42
1000
21
1544
13
2000
10
4000
5
5200
4
7000
3
10500
2
16000
1
TOKEN16
21000
1
FOX
44736
1
T3
51840
1
OC1
80000
1
ETHER100
155000
1
OC3
274000
1
T4
400000
1
SNET
622000
1
OC12
1000000
1
SNET2
1240000
1
OC24
2480000
1
OC48
10000000
1
40000000
1
T1
TOKEN4
ETHER10
Expand Configuration and Management Manual—523347-008
17 -24
SRCIPADDR n
Expand Modifiers
SRCIPADDR n
Default:
Units:
Range:
0.0.0.1
Not applicable
Any 36-character string
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the Internet Protocol (IP) address associated with the NonStop TCP/IP
process used by the local Expand-over-IP line-handler process. Because a NonStop
TCP/IP process can have more than one IP address, you must specify to the Expandover-IP line-handler process which IP address to use.
The address must be specified by number (for example, 130.252.12.3). It is not
validated and need not be accessible. Configuring IP addresses is explained in the
TCP/IP Configuration and Management Manual.
SRCIPPORT n
Default:
Units:
Range:
1024
Not applicable
0 through 65534
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the User Datagram Protocol (UDP) port number used by the local Expandover-IP line-handler process. UDP port numbers are explained in the TCP/IP
Configuration and Management Manual.
STARTUP_OFF/STARTUP_ON
Default:
Units:
Range:
STARTUP_OFF
Not applicable
ON or OFF
These Layer 2 modifiers are applicable to all Expand line-handler process types. The
STARTUP_OFF modifier specifies that the line will be disabled after a system load.
The STARTUP_ON modifier specifies that the line is brought up automatically after a
system load.
SUPERPATH_OFF/SUPERPATH_ON
Default:
Units:
Range:
SUPERPATH_OFF
Not applicable
ON or OFF
These modifiers apply to all Expand line types except for Expand-over-ServerNet and
Expand-over-FOX. The SUPERPATH_ON modifier enables the Expand multi-CPU
feature, which allows you to spread the communications load over multiple processors
by connecting multiple Expand line-handler processes, each in a separate processor,
between two adjacent nodes. These Expand line-handler processes are regarded as a
single path by the Expand subsystem. multi-line paths can be part of a multi-CPU path.
Expand Configuration and Management Manual—523347-008
17 -25
TIMERINACTIVITY n
Expand Modifiers
The Expand multi-CPU feature significantly increases the maximum throughput of an
Expand path, especially for Expand-over-IP connections.
When the SUPERPATH_ON modifier is specified and there is an existing multi-CPU
path, the new path joins the multi-CPU path. If there is no existing multi-CPU path, then
a multi-CPU path is created that has the new path as its sole member. There can be no
more than 16 multi-CPU paths in a system and each multi-CPU path can consist of no
more than 16 paths. Expand line-handler processes at both ends of the path must be
configured with SUPERPATH_ON or the multi-CPU feature is not enabled.
Expand line-handler processes that use the SUPERPATH_ON modifier also should
use congestion control. The extended packet format is required for Expand linehandler processes that are part of a multi-CPU path. For more information about
congestion control, refer to L4CONGCTRL_OFF/L4CONGCTRL_ON on page 17-14.
For more information about the extended packet format, refer to
L4EXTPACKETS_OFF/L4EXTPACKETS_ON on page 17-14.
The Expand multi-CPU feature is described in detail in Multi-CPU Feature on
page 18-74.
TIMERINACTIVITY n
Default:
Units:
Range:
900 for Expand-over-X.25 and Expand-over-SNA lines
0 (no timer) for Expand-over-IP
seconds
0 through 32767 for Expand-over-NAM lines
This modifier specifies the time interval that the Expand-over-NAM line-handler
process will wait during a period of inactivity before requesting disconnection from the
network service provided by the network access method (NAM) process, or the time
interval the Expand-over-IP line-handler process will wait during a period of user data
inactivity before suppressing non-essential maintenance traffic (netmaps) so that an
external process can disconnect from the network. In both cases, the line remains
ready and the next user data traffic brings the line out of the inactive state.
This attribute is applicable only for Expand-over-IP, Expand-over-X.25, and Expandover-SNA line-handler processes. The valid range for this attribute is 0 to 32767
seconds. The default value for Expand-over-X.25 and Expand-over-SNAX lines is
15:00 minutes (900 seconds), the default value for Expand-over-IP lines is 0 (no timer).
TIMERPROBE n
Default:
Units:
Range:
1 for Expand-over-IP and Expand-over-ATM
300 for Expand-over-X.25 and Expand-over-SNA
30 for Expand-over-FOX and Expand-over-ServerNet
seconds
1 through 32767 seconds for Expand-over-IP and Expand-over-ATM,
Expand-over-X.25 and Expand-over-SNA
30 through 32767 for Expand-over-FOX and Expand-over-ServerNet
Expand Configuration and Management Manual—523347-008
17 -26
TIMERRECONNECT n
Expand Modifiers
This specifies time interval that the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will wait to send out a probe to obtain the
status of the NAM process, or the time interval that the Expand-over-IP or Expandover-ATM line-handler process will wait to probe the remote Expand-over-IP or
Expand-over-ATM line-handler process. The time interval is specified in the format
described in Time Values on page 15-6; the time values section applies only to ALTER
PATH or ALTER LINE commands. For the ADD DEVICE command, the format of the
time is just plain seconds.
Probes will continue to be sent out the number of times specified by the
RETRYPROBE attribute. If the TIMERPROBE/RETRYPROBE cycle expires without a
returned status, the Expand-over-NAM, Expand-over-ServerNet, Expand-over-FOX,
Expand-over-ATM, or Expand-over-IP line-handler process declares the network
unavailable.
See also RETRYPROBE n and TIMERRECONNECT n.
TIMERRECONNECT n
Default:
Units:
Range:
30 for Expand-over-IP, Expand-over-ATM, and Expand-over-NAM
60 for Expand-over-ServerNet and Expand-over-FOX
seconds
30 through 32767 for Expand-over-IP, Expand-over-ATM
0 through 32767 for Expand-over-NAM, Expand-over-ServerNet, and
Expand-over-FOX
This specifies the time interval that the Expand-over-NAM, Expand-over-ATM, Expandover-IP, Expand-over-ServerNet, or Expand-over-FOX line-handler process will wait for
a connection request to succeed. The range does not include 0. The time interval is
specified in the format described in Time Values on page 15-6; the time values section
applies only to ALTER PATH or ALTER LINE commands. For the ADD DEVICE
command, the format of the time is just plain seconds.
Expand line-handler processes on opposite ends of an X25AM line should use different
values for TIMERRECONNECT.
See also RETRYPROBE n and TIMERPROBE n.
TXWINDOW n
Default:
Units:
Range:
18 for satellite-connect lines
4 for all Expand-over-NAM lines
7 for all other line types
Packets
2 through 7 for Expand-over-X.25, Expand-over FOX,
Expand-over-ServerNet, and Expand-over-NAM lines
and 2 through 25 for Expand-over-IP and Expand-over-ATM lines
This modifier is applicable to all Expand line types.
Expand Configuration and Management Manual—523347-008
17 -27
V6DESTIPADDR n
Expand Modifiers
For Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes, this modifier specifies the number of packets that the Expand line-handler
process can send before receiving acknowledgment from the network access method
(NAM) process.
For satellite-connect and direct-connect line-handler processes, this modifier specifies
the number of packets that the Expand line-handler process can send before receiving
a reply. When using the multipacket frame feature with satellite-connect line-handler
processes, you do not need to have a large TXWINDOW modifier value if the
PATHBLOCKBYTES or PATHPACKETBYTES modifier value is large.
The product of the TXWINDOW modifier value multiplied by the larger of the
PATHPACKETBYTES or PATHBLOCKBYTES modifier values must allow the space for
line buffers to fit within 131064 words. The maximum TXWINDOW modifier value is
calculated using the following formula:
maxtxwindow = int ((131064/(max(pathpacketbytes, pathblockbytes) +4)-2)/2
Therefore, a satellite-connect line with either a PATHBLOCKBYTES or
PATHPACKETBYTES modifier value of 4095 will only have space for 31 buffers. The
TXWINDOW modifier will be set to 14 and readbuffers will be set to 16, even though
the default TXWINDOW modifier value is 18. If these limits are exceeded, event
message 93, cause 8 “Attribute Invalid” is displayed: the TXWINDOW modifier value
and readbuffers will have been reduced to fit within 64K words.
For Expand-over-IP and Expand-over-ATM line-handler processes, this modifier
specifies the number of packets that the Expand-over-IP line-handler process can send
to the NonStop TCP/IP process or that the Expand-over-ATM line-handler process can
send to the ATM subsystem before waiting for a reply.
The TXWINDOW modifier value should be the same at both ends of the Expand
connection.
V6DESTIPADDR n
Default:
Units:
Range:
0000:0000:0000:0000:0000:0000:0000:0000
Not applicable
Any 45-character string
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the destination Internet Protocol (IP) address associated with the NonStop
TCP/IPv6 process used by the remote Expand-over-IP line-handler process.
The default must be changed before the line is started. The address must be specified
by number (for example, 1611:1071:F881:1167:1611:A071:1881:B167). Configuring
NonStop TCP/IPv6 addresses is explained in the TCP/IPv6 Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
17 -28
V6SRCIPADDR n
Expand Modifiers
V6SRCIPADDR n
Default:
Units:
Range:
0000:0000:0000:0000:0000:0000:0000:0000
Not applicable
Any 45-character string
This modifier is applicable to Expand-over-IP line-handler processes only. This modifier
specifies the source Internet Protocol (IP) address associated with the NonStop
TCP/IPv6 process used by the local Expand-over-IP line-handler process. Because a
NonStop TCP/IPv6 process can have more than one IP address, you must specify to
the Expand-over-IP line-handler process which IP address to use.
The default must be changed before the line is started. The address must be specified
by number (for example, 31CA:B145:5489:1034:1784:B245:4029:1257). Configuring
NonStop TCP/IPv6 addresses is explained in the TCP/IPv6 Configuration and
Management Manual.
Profiles
This subsection lists the modifiers that are contained in each of the profiles.
Single-Line Expand Line-Handler Process Modifiers
Table 17-3 lists the modifiers in the profiles provided for single-line Expand line-handler
processes.
Table 17-3. Single-Line Path Modifiers (page 1 of 3)
Modifier
PEXQSSWN
PEXQSSAT
PEXQSIP
PEXQATM
PEXQSNAM
PEXPSSN
PEXQSFX
AFTERMAXRETRIES_
DOWN
X
X
X
X
X
AFTERMAXRETRIES_
PASSIVE
X
X
X
X
X
ASSOCIATEDEV
X
X
X
X
X
ASSOCIATESUBDEV
X
X
ATMSEL
X
CALLTYPE_ATMSAP
X
CALLTYPE_PVC
X
CALLTYPE_SVC
X
CLOCKMODE_DCE
X
X
CLOCKMODE_DTE
X
X
CLOCKSPEED_600
X
X
CLOCKSPEED_1200
X
X
CLOCKSPEED_2400
X
X
Expand Configuration and Management Manual—523347-008
17 -29
Single-Line Expand Line-Handler Process Modifiers
Expand Modifiers
Table 17-3. Single-Line Path Modifiers (page 2 of 3)
Modifier
PEXQSSWN
PEXQSSAT
CLOCKSPEED_4800
X
X
CLOCKSPEED_9600
X
X
CLOCKSPEED_19200
X
X
CLOCKSPEED_38400
X
X
CLOCKSPEED_56000
X
X
CLOCKSPEED_115200 X
X
COMPRESS_OFF
X
COMPRESS_ON
X
PEXQSIP
PEXQATM
PEXQSNAM
PEXPSSN
PEXQSFX
X
X
X
X
X
X
X
X
X
X
X
X
CONNECTTYPE_
ACTIVEANDPASSIVE
X
X
X
X
X
CONNECTTYPE_
PASSIVE
X
X
X
X
X
DELAY
X
X
DESTATMADDR
X
DESTIPADDR
X
DESTIPPORT
X
DOWNIFBADQUALITY_ X
OFF
X
X
X
DOWNIFBADQUALITY_ X
ON
X
X
X
EXTMEMSIZE
X
X
X
X
X
X
X
FLAGFILL_OFF
X
X
FLAGFILL_ON
X
X
FRAMESIZE
X
X
X
X
X
X
X
INTERFACE_RS232
X
X
INTERFACE_RS422
X
X
X
X
X
X
X
IPVER_IPV4
X
IPVER_IPV6
X
L2DISCARDONRESET_ X
OFF
X
L2DISCARDONRESET_ X
ON
X
L2RETRIES
X
X
L2TIMEOUT
X
X
L4CONGCTRL_OFF
X
X
X
X
X
X
X
L4CONGCTRL_ON
X
X
X
X
X
X
X
L4EXTPACKETS_OFF X
X
X
X
X
X
X
Expand Configuration and Management Manual—523347-008
17 -30
Single-Line Expand Line-Handler Process Modifiers
Expand Modifiers
Table 17-3. Single-Line Path Modifiers (page 3 of 3)
Modifier
PEXQSSWN
PEXQSSAT
PEXQSIP
PEXQATM
PEXQSNAM
PEXPSSN
PEXQSFX
L4EXTPACKETS_ON
X
X
X
X
X
X
X
L4RETRIES
X
X
X
X
X
X
X
L4SENDWINDOW
X
X
X
X
X
X
X
L4TIMEOUT
X
X
X
X
X
X
X
LIFNAME
X
LINEPRIORITY
X
X
X
X
X
X
X
LINETF
X
X
X
X
X
X
X
X
X
X
X
X
MAXRECONNECTS
NEXTSYS
X
X
X
X
X
X
X
OSSPACE
X
X
X
X
X
X
X
OSTIMEOUT
X
X
X
X
X
X
X
PATHBLOCKBYTES
X
X
X
X
X
X
X
PATHPACKETBYTES
X
X
X
X
X
X
X
PATHTF
X
X
X
X
X
X
X
PROGRAM
X
X
PVCNAME
X
QUALITYTHRESHOLD X
X
X
X
QUALITYTIMER
X
X
X
X
X
X
X
X
X
RETRYPROBE
RXWINDOW
X
X
X
X
X
X
X
SPEED
X
X
X
X
X
X
X
SPEEDK
X
X
X
X
X
X
X
SRCIPADDR
X
SRCIPPORT
X
STARTUP_OFF
X
X
X
X
X
X
X
STARTUP_ON
X
X
X
X
X
X
X
SUPERPATH_OFF
X
X
X
X
X
X
X
SUPERPATH_ON
X
X
X
X
X
TIMERINACTIVITY
X
TIMERPROBE
X
X
X
X
X
TIMERRECONNECT
X
X
X
X
X
X
X
X
X
X
TXWINDOW
X
X
V6DESTIPADDR
X
V6SRCIPADDR
X
X
Expand Configuration and Management Manual—523347-008
17 -31
Multi-Line Path Modifiers
Expand Modifiers
Multi-Line Path Modifiers
The following modifiers are included in the PEXPPATH profile provided for path logical
devices:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
COMPRESS_OFF
COMPRESS_ON
L4CONGCTRL_OFF
L4CONGCTRL_ON
L4EXTPACKETS_OFF
L4EXTPACKETS_ON
L4RETRIES
L4SENDWINDOW
L4TIMEOUT
NEXTSYS
OSSPACE
OSTIMEOUT
PATHBLOCKBYTES
PATHPACKETBYTES
PATHTF
SUPERPATH_OFF
SUPERPATH_ON
Table 17-4 lists the modifiers in the profiles provided for line-logical devices.
Table 17-4. Modifiers for Line-Logical Devices (page 1 of 3)
Modifier
PEXQMSWN
PEXQMSAT
PEXQMNAM
PEXQMIP
PEXQATM
AFTERMAXRETRIES_
DOWN
X
X
X
AFTERMAXRETRIES_
PASSIVE
X
X
X
ASSOCIATEDEV
X
X
X
ASSOCIATESUBDEV
X
X
ATMSEL
X
CALLTYPE_ATMSAP
X
CALLTYPE_PVC
X
CALLTYPE_SVC
X
CLOCKMODE_DCE
X
X
CLOCKMODE_DTE
X
X
CLOCKSPEED_600
X
X
CLOCKSPEED_1200
X
X
CLOCKSPEED_2400
X
X
CLOCKSPEED_4800
X
X
CLOCKSPEED_9600
X
X
Expand Configuration and Management Manual—523347-008
17 -32
Multi-Line Path Modifiers
Expand Modifiers
Table 17-4. Modifiers for Line-Logical Devices (page 2 of 3)
Modifier
PEXQMSWN
PEXQMSAT
CLOCKSPEED_19200
X
X
CLOCKSPEED_38400
X
X
CLOCKSPEED_56000
X
X
PEXQMNAM
PEXQMIP
PEXQATM
CONNECTTYPE_
ACTIVEANDPASSIVE
X
X
X
CONNECTTYPE_PASSIVE
X
X
X
CLOCKSPEED_115200
DELAY
X
X
DESTATMADDR
X
DESTIPADDR
X
DESTIPPORT
X
DOWNIFBADQUALITY_OFF
X
X
X
X
DOWNIFBADQUALITY_ON
X
X
X
X
FLAGFILL_OFF
X
X
FLAGFILL_ON
X
X
FRAMESIZE
X
X
X
X
INTERFACE_RS232
X
X
INTERFACE_RS422
X
X
X
IPVER_IPV4
X
IPVER_IPV6
X
L2DISCARDONRESET_OFF
X
X
L2DISCARDONRESET_ON
X
X
L2RETRIES
X
X
L2TIMEOUT
X
X
X
X
LIFNAME
X
X
LINEPRIORITY
X
X
X
X
X
LINETF
X
X
X
X
X
X
X
X
MAXRECONNECTS
QUALITYTHRESHOLD
X
X
X
X
QUALITYTIMER
X
X
X
X
PROGRAM
X
X
PVCNAME
X
RETRYPROBE
X
X
X
RXWINDOW
X
X
X
X
X
SPEED
X
X
X
X
X
Expand Configuration and Management Manual—523347-008
17 -33
Multi-Line Path Modifiers
Expand Modifiers
Table 17-4. Modifiers for Line-Logical Devices (page 3 of 3)
Modifier
PEXQMSWN
PEXQMSAT
PEXQMNAM
PEXQMIP
PEXQATM
SPEEDK
X
X
X
X
X
SRCIPADDR
X
SRCIPPORT
X
STARTUP_OFF
X
X
X
X
X
STARTUP_ON
X
X
X
X
X
TIMERINACTIVITY
X
X
TIMERPROBE
X
X
X
TIMERRECONNECT
X
X
X
X
X
X
TXWINDOW
X
X
V6DESTIPADDR
X
V6SRCIPADDR
X
Expand Configuration and Management Manual—523347-008
17 -34
18
Subsystem Description
This section provides a high-level technical description of the architecture and
dynamics of the Expand subsystem. You should be familiar with the information
presented in this section before you attempt to configure, manage, or troubleshoot the
Expand subsystem.
The following topics are explained in this section:
•
•
•
•
•
•
•
•
•
•
•
•
•
Expand Subsystem Components on page 18-2
Expand Subsystem and the OSI Reference Model on page 18-9
Path Function of the Expand Subsystem on page 18-13
Routing and Time Factors on page 18-22
Message Handling and Buffer Allocation on page 18-38
Message Buffering on page 18-46
Expand-to-NAM Interface on page 18-49
Expand-to-IP Interface on page 18-54
Expand-to-ATM Interface on page 18-59
Multipacket Frame Feature on page 18-64
Variable Packet Size Feature on page 18-68
Congestion Control Feature on page 18-71
Multi-CPU Feature on page 18-74
Expand Configuration and Management Manual—523347-008
18- 1
Expand Subsystem Components
Subsystem Description
Expand Subsystem Components
The Expand subsystem comprises the following major components:
•
•
•
Expand Line-Handler Processes on page 18-2
Network Control Process ($NCP) on page 18-7
Expand Manager Process ($ZEXP) on page 18-7
Expand Line-Handler Processes
An Expand line-handler process is responsible for
•
•
•
•
Maintaining the communications path between two adjacent nodes. A path is a
logical connection that can consist of one or more parallel lines. A line is a single
physical communications link between two nodes.
Implementing the HP proprietary End-to-End protocol. The End-to-End protocol
is explained in Path Function of the Expand Subsystem on page 18-13.
Establishing a connection with an X.25 Access Method (X25AM) line-handler
process, a SNAX/Advanced Peer Networking (SNAX/APN) line-handler process, a
NonStop TCP/IP process, the ServerNet monitor process ($ZZSCL), or the FOX
monitor process ($ZZFOX), if these communications methods are used.
Forwarding packets addressed to other nodes.
Each system in an Expand network can contain as many as 255 Expand line-handler
processes.
Expand Path Types
You can configure an Expand path as
•
•
•
A single-line path, which is a path that consists of one line.
A multi-line path, which is a path that consists of more than one line. You can
configure a multi-line path to consist of up to eight parallel lines.
A member of a multi-CPU path, which is a path that consists of more than one
path. You can configure a multi-CPU path to consist of up to 16 parallel paths,
including multi-line paths.
An Expand line-handler process that manages a single line performs both path and line
functions with a single logical device.
A multi-line path requires a logical device to manage the path function (called a path
logical device) and a separate logical device for each line in the path (called a line
logical device). Each line logical device is associated with the path logical device that
manages the path to which the line belongs. The path logical device and the line
logical devices with which it is associated are regarded as a single Expand line-handler
process and must be configured in the same processor pair.
Expand Configuration and Management Manual—523347-008
18- 2
Expand Line-Handler Processes
Subsystem Description
A multi-CPU path is created by associating Expand line-handler processes with one
another using the SUPERPATH_ON modifier. Each line-handler process that is a
member of a multi-CPU path is configured in a different processor.
Note. The path and line functions of an Expand line-handler process are described in more
detail in Expand Subsystem and the OSI Reference Model on page 18-9.
Expand Line-Handler Process Types
Expand line-handler processes can be categorized as follows:
•
•
Those that contain all the protocol levels necessary to perform both path and line
functions. These include the following types of Expand line-handler processes:
°
°
Direct-connect
Satellite-connect
Those that require another type of process to perform line functions. These include
the following types of Expand line-handler processes:
°
°
°
°
°
Expand-over-NAM
Expand-over-IP
Expand-over-ServerNet
Expand-over-FOX
Expand-over-ATM
The different types of Expand line-handler processes are described in the following
subsections. For information on how to configure Expand line-handler processes, refer
to Section 5, Configuration Overview.
Direct-Connect and Satellite-Connect Expand Line-Handler
Processes
The direct-connect line-handler process implements the High-Level Data Link Control
(HDLC) Normal protocol. This type of Expand line-handler process is provided for use
with conventional voice-grade leased-line and switched-line facilities, private facilities,
and fractional Transmission Group 1 (T1) facilities.
The satellite-connect line-handler process implements the satellite-efficient version of
the HDLC protocol, the HDLC Extended Mode protocol. Unlike the HDLC Normal
protocol implemented by direct-connect Expand line-handler processes, the HDLC
Extended Mode protocol uses the maximum window size of 61 frames (the maximum
number of outstanding frames before an acknowledgment is required) and implements
the selective reject feature. Selective reject causes only frames that arrive in error to
be retransmitted.
Expand Configuration and Management Manual—523347-008
18- 3
Expand Line-Handler Processes
Subsystem Description
Although the satellite-connect line-handler process is provided for use with satellite
connections, it can also be used to manage terrestrial lines. This type of configuration
can enhance the reliability of terrestrial lines that carry small messages at high speeds.
Expand-Over-NAM Line-Handler Processes
Expand-over-NAM line-handler processes use the NETNAM protocol to access the
network access method (NAM) interface provided by an X25AM or a SNAX/APN
line-handler process.
Note. For more information about the Expand-to-NAM interface, refer to Expand-to-NAM
Interface on page 18-49.
Expand-Over-NAM With X25AM
The X25AM subsystem provides access to X.25 packet-switched data networks
(PSDNs). The X25AM subsystem consists of a layered set of protocols that
corresponds to the lower three layers of the International Standards Organization (ISO)
Open Systems Interconnection (OSI) Reference Model.
Each X25AM line-handler process controls a single data communications line and
supports both permanent virtual circuits (PVCs) and switched virtual circuits (SVCs).
Up to 254 circuits can be configured for each X25AM line-handler process. One
X25AM line-handler process can service multiple Expand-over-NAM line-handler
processes.
When it interfaces to an X25AM line-handler process, the Expand-over-X.25 linehandler process sends data over one virtual circuit running in the X25AM line-handler
process; the X25AM line-handler process manages the physical communications line.
The Expand-over-X.25 line-handler process is also responsible for
•
•
•
Establishing the connection between itself and the X25AM line-handler process
Reestablishing communications with the remote server when an unavailable
network service becomes available again
Error recovery
Expand-Over-NAM With SNAX/APN
The SNAX/APN subsystem provides access to IBM Systems Network Architecture
(SNA) networks. The SNA network can be a traditional network of host mainframes
and front end processors, an advanced peer-to-peer network of IBM AS400 systems,
or a mix of these two types of networks. SNAX access methods support a wide range
of physical connections to IBM systems and networks, including
•
•
•
Synchronous Data Link Control (SDLC) connections, using RS-232, RS-449, X.21,
and V.35 electrical interfaces
X.25 packet-switched networks
Token Ring networks
Expand Configuration and Management Manual—523347-008
18- 4
Expand Line-Handler Processes
Subsystem Description
•
Host channel connections
The SNAX/APN subsystem consists of a service-manager process and one or more
SNAX/APN line-handler processes. Each Expand-over-SNA line-handler process is
configured to use a particular SNAX/APN line and logical unit (LU). At least one
SNAX/APN line and one Expand line must be configured and started at each end of
the SNA network through which the Expand-over-SNA line-handler processes will
communicate.
Expand-Over-IP Line-Handler Process
The Expand-over-IP line-handler process uses the NonStop TCP/IP subsystem to
provide connectivity to an Internet Protocol (IP) network.
The Expand-over-IP line-handler process is a client to a NonStop TCP/IP process. The
Expand-over-IP process communicates with the NonStop TCP/IP process through the
shared memory of the QIO subsystem.
The NonStop TCP/IP process provides a Guardian file-system interface to the
Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), as well
as raw (direct) access to IP. The Expand-over-IP line-handler process uses the UDP
services provided by the TCP/IP process to transmit data across an IP network.
Note. For more detailed information about the Expand-to-IP interface, refer to Expand-to-IP
Interface on page 18-54.
Expand-Over-ServerNet Line-Handler Process
The Expand-over-ServerNet line-handler process uses a pair of NonStop cluster
switches, Modular ServerNet expansion boards (MSEBs), plug-in cards (PICs), fiberoptic cables, and the ServerNet monitor process ($ZZSCL) to connect to a ServerNet
cluster.
Each ServerNet cluster uses at least two NonStop cluster switches for routing; one for
the X-fabric and one for the Y-fabric. For the star topology, introduced with the G06.09
RVU, these switches can support up to eight nodes per switch. For the split-star
topology, introduced with the G06.12 RVU, two switches for each fabric can support up
to 16 nodes (eight nodes per switch). For the tri-star topology, introduced with the
G06.14 RVU, three switches for each fabric can support up to 24 nodes (eight nodes
per switch). For more information about the cluster switches, refer to the ServerNet
Cluster Manual.
Each switch connects to two MSEBs per node. At least two plug-in cards are required
for ServerNet connections between system enclosures in each node. Two fiber-optic
cables are required for each node, for attachment to the X and Y cluster switches. The
Expand Configuration and Management Manual—523347-008
18- 5
Expand Line-Handler Processes
Subsystem Description
Expand-over-ServerNet line-handler process uses the NETNAM protocol to access the
NAM interface of the ServerNet cluster monitor process ($ZZSCL).
Note. For more information about the Expand-to-NAM interface, refer to Expand-to-NAM
Interface on page 18-49.
The Expand-over-ServerNet line-handler process manages security-related messages
and forwards packets outside the ServerNet cluster. Other messages, such as
incoming and outgoing data, usually bypass the Expand-over-ServerNet line-handler
process and are handled directly by the ServerNet fabrics and the NonStop cluster
switches; the Expand software is not involved.
Expand-Over-FOX Line-Handler Process
The Expand-over-FOX line-handler process uses a pair of ServerNet/Fiber eXtension
(ServerNet/FX) adapters, fiber-optic cables, the FOX monitor process ($ZZFOX), and
the FOX driver to connect to a FOX ring.
One ServerNet/FX adapter is connected through the ServerNet system area network
(ServerNet SAN) to the X-ring and a second ServerNet/FX adapter is connected
through the ServerNet SAN to the Y-ring. $ZZFOX is a generic process that is
responsible for maintaining configuration information about the FOX ring and is the
manager process for the ServerNet/FX adapters. The Expand-over-FOX line-handler
process uses the NETNAM protocol to access the NAM interface of $ZZFOX.
Note. For more information about the Expand-to-NAM interface, refer to Expand-to-NAM
Interface on page 18-49.
The FOX driver is responsible for communicating directly with the ServerNet/FX
adapters. It is provided as part of the NonStop Kernel operating system. The Expandover-FOX line-handler process manages security-related messages and forwards
packets outside the FOX ring. Other messages, such as incoming and outgoing data,
usually bypass the Expand-over-FOX line-handler process and are handled directly by
the ServerNet fabrics and the ServerNet/FX adapters; the Expand software is not
involved.
Expand-Over-ATM Line-Handler Process
The Expand-over-ATM line-handler process uses the Asynchronous Transfer Mode
(ATM) subsystem to provide connectivity to an ATM network. The Expand-over-ATM
line-handler process communicates with the ATM subsystem through the shared
memory of the QIO subsystem.
The ATM subsystem, which is HP’s implementation of the ATM protocol, consists of
hardware and software components that reside on a NonStop S-series server. The
ATM 3 ServerNet adapter (ATM3SA) provides one bidirectional full-duplex ATM OC3
port for connection to the User-Network Interface (UNI). The Expand-over-ATM linehandler process uses the services provided by the ATM subsystem to transmit data
across an ATM network.
Expand Configuration and Management Manual—523347-008
18- 6
Network Control Process ($NCP)
Subsystem Description
Note. For more detailed information about the Expand-to-ATM interface, refer to Expand-toATM Interface on page 18-59.
Network Control Process ($NCP)
The network control process, $NCP, is a process in each node of an Expand network.
$NCP uses services provided by the network utility process, $ZNUP. $ZNUP is part of
the NonStop Kernel operating system.
Network Control Process Functions
The network control process, $NCP, is responsible for the following functions:
•
•
•
•
•
•
•
Initiating and terminating node-to-node connections.
Maintaining the network-related system tables, including routing information.
Calculating the most efficient way to transmit data to other nodes in the network.
Monitoring and logging changes in the status of the network and its nodes.
Informing the network control processes at neighbor nodes of changes in line or
Expand line-handler process status (for example, lines UP or DOWN). Neighbor
nodes are two nodes that have a path configured between them.
Informing Expand line-handler processes when all paths are DOWN. Expand linehandler processes respond by aborting pending requests.
Grouping Expand line-handler processes in a multi-CPU path to a particular
neighbor node.
The network control process runs as logical device number 1.
Network Utility Process Functions
The network utility process, $ZNUP, answers requests that must wait for system
information. It also responds to requests for the time at remote systems, the process
information of remote processes, device-information requests, and traffic statistics.
The network utility process runs as logical device number 4.
Expand Manager Process ($ZEXP)
The Expand manager process, $ZEXP, provides the interface between the Expand
subsystem and the Subsystem Control Point (SCP). The Expand manager process
must be started and named $ZEXP. SCP is the managing process for the Subsystem
Control Facility (SCF). The Expand manager process directs SCF commands to the
appropriate Expand line-handler process and forwards responses from Expand linehandler processes to the appropriate user.
Expand Configuration and Management Manual—523347-008
18- 7
Components Summary
Subsystem Description
Note. The SCF interface to the Expand subsystem is described in Section 15, Subsystem
Control Facility (SCF) Commands.
Components Summary
Figure 18-1 illustrates an Expand network environment.
Figure 18-1. Expand Network Environment
Node \B
Node \A
Server
Application
Requester
Application
Kernel
Kernel
$ZNUP
$ZNUP
File
System
Message
System
Expand
Message
System
File
System
Server
Application
Requester
Application
Expand
Expand LineHandler
Process
Expand LineHandler
Process
$NCP
$NCP
$ZEXP
$ZEXP
CDT 010.CDD
Expand Configuration and Management Manual—523347-008
18- 8
Expand Subsystem and the OSI Reference Model
Subsystem Description
Expand Subsystem and the OSI Reference
Model
The Expand line-handler process and $NCP components of the Expand subsystem
contain some of the functions defined in the lower five layers of the OSI Reference
Model. The Expand subsystem does not provide any Application Layer or Presentation
Layer functions; these functions, in addition to some Session Layer functions, are
provided by the message and file systems.
This subsection describes the following topics:
•
•
Expand Line-Handler Process Layer Functions on page 18-10
$NCP Layer Functions on page 18-12
Figure 18-2 compares the Expand subsystem’s protocol layers to the OSI Reference
Model.
Note. The Expand subsystem was not designed to match the OSI framework. The OSI
Reference Model is used in the following discussion as a common point of reference to help
explain the functions of the various layers of the Expand subsystem.
Figure 18-2. Expand Subsystem Protocol Layers
Expand
OSI Layers
User Applications
Message and File
Systems
Application Layer (7)
Presentation Layer (6)
Session Layer (5)
Expand LineHandler
Process
Transport Layer (4)
$NCP
Network Layer (3)
Data Link Layer (2)
Communications
Hardware
Physical Layer (1)
CDT 011.CDD
Expand Configuration and Management Manual—523347-008
18- 9
Expand Line-Handler Process Layer Functions
Subsystem Description
Expand Line-Handler Process Layer Functions
An Expand line-handler process implements several different protocols, including the
HP proprietary End-to-End protocol. These protocols provide some of the functions
defined by the lower five layers of the OSI Reference Model.
OSI Session Layer (Layer 5)
The OSI Session Layer coordinates processes and is responsible for the setup and
termination of a communications path.
The following path functions of the End-to-End protocol correspond to some of the OSI
Session Layer functions:
•
•
System-to-system connection establishment and termination
Security processing (remote passwords, accessing Safeguard)
OSI Transport Layer (Layer 4)
The OSI Transport Layer accepts data from the OSI Session Layer and passes it to the
OSI Network Layer. The OSI Transport Layer provides end-to-end data integrity
between processes and verifies that messages received are correct.
The following path functions of the End-to-End protocol correspond to some of the OSI
Transport Layer functions:
•
•
•
•
Message management and buffering between processes (end-to-end). This
includes reassembling messages from incoming packets and multiplexing
outbound messages over available lines
Request/response matching
Flow control
Canceled-request handling
The Transport Layer, or path function, of the Expand line-handler process corresponds
to the Expand SCF PATH object.
OSI Network Layer (Layer 3)
The OSI Network Layer governs the switching and routing of information between
nodes in the network and is responsible for error-checking and recovery.
The following line functions of the End-to-End protocol correspond to some of the OSI
Network Layer functions:
•
•
Routing incoming passthrough traffic to another Expand line-handler process
Error-checking and recovery
The Network Layer, or path function, of the Expand line-handler process corresponds
to the Expand SCF PATH object.
Expand Configuration and Management Manual—523347-008
18 -10
Expand Line-Handler Process Layer Functions
Subsystem Description
OSI Data Link Layer (Layer 2)
The OSI Data Link Layer defines the rules for transmission on the physical medium.
Direct-connect line-handler processes provide one of the following versions of the
High-Level Data Link Control (HDLC) protocol at the Data Link Layer depending on the
communications device used:
•
•
HDLC using Asynchronous Balanced Mode (HDLC-ABM)
HDLC-ABM using Transparent Byte Synchronous Framing
Satellite-connect line-handler processes provide the HDLC protocol using
Asynchronous Balanced Mode Extended (HDLC-ABME) at the Data Link Layer.
Expand-over-NAM line-handler processes use the Data Link Layer services provided
by an X25AM (Expand-over-X.25) or SNAX/APN (Expand-over-SNA) line-handler
process.
Expand-over-IP line-handler processes use the NETIP protocol at the Data Link
Layer. The NETIP protocol provides Expand-over-IP line-handler processes with a
QIO-based interface to send Layer 2 frames over IP-based networks via TCP/IP.
Expand-over-ATM line-handler processes use the NETATM protocol at the Data Link
Layer. The NETATM protocol provides Expand-over-ATM line-handler processes with a
QIO-based interface to send Layer 2 frames over ATM-based networks.
Expand-over-ServerNet line-handler processes use the Data Link Layer services
provided by the ServerNet monitor process, $ZZSCL.
Expand-over-FOX line-handler processes use the Data Link Layer services provided
by the FOX monitor process, $ZZFOX.
The Data Link Layer, or line function, of the Expand line-handler process corresponds
to the Expand SCF LINE object.
OSI Physical Layer (Layer 1)
The OSI Physical Layer provides the ability to transmit and receive bits between
nodes. It specifies the physical medium used and defines the electrical interfaces to
the network and the bit-level data flow.
The Physical Layer (Layer 1) of the Expand subsystem includes the drivers, interrupt
handlers, and hardware communications devices that control the physical line.
Expand-over-IP connections are provided through the Ethernet 4 ServerNet adapter
(E4SA) or the ATM 3 ServerNet adapter (ATM3SA). Expand-over-ATM connections are
provided through the ATM3SA.
The ServerNet wide area network (SWAN) concentrator provides WAN connections for
direct-connect, satellite-connect, Expand-over-X.25, and Expand-over-SNA
connections. SWAN concentrators are connected to the server through dual E4SAs.
The ServerNet/FX adapter provides Expand-over-FOX connections.
Expand Configuration and Management Manual—523347-008
18 -11
$NCP Layer Functions
Subsystem Description
The End-to-End protocol is described in Path Function of the Expand Subsystem on
page 18-13.
$NCP Layer Functions
As shown in Figure 18-2, $NCP provides some functions of both the OSI Transport
and Network Layers.
$NCP at the OSI Transport Layer
$NCP provides part of the OSI Transport Layer function because it monitors processor
UP and DOWN notifications.
$NCP at the OSI Network Layer
$NCP provides the following OSI Transport Layer functions:
•
•
•
•
Maintaining network routing information
Calculating the most efficient way to transmit data to other nodes in the network
Exchanging routing information with $NCPs at neighbor nodes
Grouping the Expand line-handler processes in a multi-CPU path to a particular
neighbor node
Expand Configuration and Management Manual—523347-008
18 -12
Path Function of the Expand Subsystem
Subsystem Description
Path Function of the Expand Subsystem
This subsection describes the end-to-end (Layer 3) and packet routing (Layer 4)
messages that are generated by the End-to-End protocol. Layers 3 and 4 of the Endto-End protocol provide the path function of the Expand subsystem.
This subsection describes the following topics:
•
•
•
•
Protocol Packet Types on page 18-13
Packet Synchronization on page 18-16
Example of End-to-End Protocol Packet Exchanges on page 18-16
Layer 4 Send Window on page 18-21
You must be familiar with the information in this subsection before you can effectively
tune or troubleshoot an Expand network. Layer 3 and Layer 4 protocol statistics are
reported by the Expand SCF STATS PATH command.
Note. This subsection does not describe the protocols used by Expand line-handler processes
at the OSI Data Link Layer (Layer 2). For information regarding standards such as HDLC and
X.25, refer to the documentation provided for these standards.
Protocol Packet Types
The End-to-End protocol defines the following types of packets:
Connection Request (CONN REQ)
A CONN REQ is a connection-establishment–request-setup packet. Before data can
be exchanged between two nodes over one or more physical lines, a logical
communications path must be opened between the nodes. $NCP selects the best path
to the destination node and directs the Expand line-handler process to send a CONN
REQ packet, which is the first packet to be sent by $NCP when a logical
communications path is to be opened.
Connection Response (CONN RSP)
A CONN RSP is a connection-establishment–response-setup packet. This packet is
sent by $NCP when it receives a CONN REQ packet, which indicates to the requesting
$NCP that the responding $NCP is available for connection establishment.
Connection Acknowledgment (CONN ACK)
A CONN ACK is a connection-establishment–acknowledgment-setup packet. This
packet is sent by $NCP when it receives a CONN RSP packet, which confirms to both
the requesting and the responding $NCPs that a logical connection has been
established.
Expand Configuration and Management Manual—523347-008
18 -13
Protocol Packet Types
Subsystem Description
Connection Reset (CONN RST)
A CONN RST is a connection-establishment–reset-setup packet. This packet is sent
by $NCP at one of the two end nodes if a packet sequence problem is detected during
connection establishment.
Node Status (NODE STAT)
A NODE STAT is a connection-establishment–system-status setup packet. This packet
is sent only from C-series nodes and is exchanged by the requesting and responding
$NCP to inform the other $NCP of its respective processor status and operating
system version numbers. NODE STAT packets must be exchanged before any other
data can be exchanged over a logical connection.
Note. For D-series and G-series nodes, the processor status and operating system version
numbers are sent in the connection-establishment request/reply packets.
Node Status Acknowledgment (NODE ACK)
A NODE ACK is a connection-establishment–system-status acknowledgment setup
packet. This packet is exchanged by the requesting and responding $NCPs to
acknowledge the receipt of a NODE STAT packet. The exchange of this packet
completes the logical connection-establishment setup between $NCP at two C-series
end nodes.
Link Request (LRQ)
An LRQ is a request data packet. LRQ packets are exchanged between Expand linehandler processes over an open communications path. The buffer used to hold the
LRQ is not deallocated until a response to the LRQ is received.
A single request message may require multiple LRQ packets. The first LRQ includes
request-message size information. The recipient of the LRQ uses the request message
size information to allocate sufficient buffer space to receive the request message.
LRQs also include a MORE bit to indicate that additional LRQs will be sent.
Link Complete (LCMP)
An LCMP is a reply data packet. These packets are exchanged between Expand linehandler processes over an open communications path.
A single reply message may require multiple LCMP packets. A reply message is sent
in response to each request message whether or not data is requested by the sender
of the request message (the requester). When the requester receives an LCMP, it uses
the buffer space initially allocated for the LRQ to receive the LCMP. Once all the
LCMPs have been received, the buffer is deallocated.
Expand Configuration and Management Manual—523347-008
18 -14
Protocol Packet Types
Subsystem Description
Link Cancel Request (LCAN)
An LCAN is a control packet that is sent in response to a user request to abort a prior
LRQ.
Data Packet Acknowledgment (ACK)
An ACK is a control packet. It is a positive acknowledgment of a data packet (either an
LRQ or an LCMP). LRQ and LCMP packets can include acknowledgments. An ACK is
only used to acknowledge data packets if no other data packets are ready to be sent.
Negative Data Packet Acknowledgment (NAK)
A NAK is a control packet. It is a negative acknowledgment of a data packet (either an
LRQ or an LCMP) and is evidence of some type of network trouble or potential
configuration mismatch.
Data Packet Enquiry (ENQ)
An ENQ is a control packet. If a data packet (either an LRQ or an LCMP) is not
acknowledged within the Expand Level 4 timeout period, the sending Expand linehandler process sends an ENQ, and the Level 4 timer is reset and restarted. The
sending line-handler process continues to send ENQs each time the Level 4 timeout
expires until one of the following occurs:
•
•
•
The request is acknowledged.
The Expand Level 4 retry limit has been reached.
An LCMP corresponding to an LRQ is received before the LRQ is acknowledged.
Note. You can control the Expand Level 4 timeout and retry limits by setting the L4TIMEOUT
and L4RETRIES modifiers. These modifiers are explained in Section 17, Expand Modifiers.
Path Change Status (PCHG CMD)
A PCHG CMD is a path-status-notification change packet. It is exchanged by the
Expand line-handler processes at neighbor nodes when the path status between the
two nodes changes and there are still active lines remaining.
Path Change Status Response (PCHG RSP)
A PCHG RSP is a path-status-response change packet. It is sent by an Expand linehandler process to another Expand line-handler process in response to a PCHG CMD
packet.
Expand Configuration and Management Manual—523347-008
18 -15
Packet Synchronization
Subsystem Description
Trace Request (TRACE)
A TRACE is a data packet that is sent in response to an SCF PROBE command. It
contains the identifier of each node it encounters on its route from its sender to its
receiver.
PING Message
A PING message is sent by an Expand line-handler process to measure the round trip
time to a neighbor node. The information obtained by sending a PING message is
used to calculate the effective time factor (ETF) of a path that is a member of a multiCPU path. For more information about PING messages, refer to Calculating Route
Time Factors on page 18-27.
Packet Synchronization
Each End-to-End protocol packet includes a sequence number that is used for
synchronization.
LRQs and LCMPs are numbered sequentially. The first LRQ sent is sequence number
0, the second is sequence number 1, and so on.
ACK sequence numbers indicate the acknowledgment of specific LRQs and LCMPs.
For example, an ACK sequence number of 3 acknowledges the receipt of LRQs with
sequence numbers up to but not including 3. In Figure 18-3, the first ACK sent from
node \A acknowledges LRQ sequence numbers 0, 1, and 2.
NAK sequence numbers indicate the negative acknowledgment of specific requests.
For example, a NAK sequence number 1 indicates that LRQ sequence number 0 was
received but that LRQ sequence number 1 was not. Figure 18-4 shows an example of
NAK sequence numbering.
ENQ sequence numbers indicate how many packets have been sent. For example,
when an ENQ sequence number 3 is sent, the sender is telling the recipient that it has
sent packets with sequence numbers up to but not including 3. Figure 18-5 shows an
example of ENQ sequence numbering.
Example of End-to-End Protocol Packet Exchanges
Figure 18-3, Figure 18-4, Figure 18-5, and Figure 18-6 illustrate four different End-toEnd protocol packet exchanges. Figure 18-3 shows an error-free exchange of data; the
remaining figures illustrate how the protocol recovers from problem situations.
Expand Configuration and Management Manual—523347-008
18 -16
Example of End-to-End Protocol Packet Exchanges
Subsystem Description
Normal Data Exchange
Figure 18-3 is an example of an error-free exchange of data. Node \A sends two LRQs
to node \B. Node \B sends ACK sequence number 2 to indicate the positive
acknowledgment of node \A’s LRQs and then replies to each LRQ with an LCMP. Node
\A acknowledges node \B’s LCMPs by sending ACK sequence number 2.
Note. The sequence number of an LCMP does not necessarily match the sequence number of
a corresponding LRQ. The explicit ACK may not be seen if other data packets are being
transmitted.
Figure 18-3. Normal Exchange
NODE \A
NODE \B
LRQ (0)
LRQ (1)
ACK (2)
LCMP (0)
LCMP (1)
ACK (2)
CDT 012.CDD
Expand Configuration and Management Manual—523347-008
18 -17
Example of End-to-End Protocol Packet Exchanges
Subsystem Description
Data Exchange With Lost Data
Figure 18-4 shows a data exchange in which a packet is not received. This problem is
usually caused by network congestion and/or line failures and is indicated by a large
number of NAKs on the SCF STATS display.
Figure 18-4. Lost Data
NODE \A
NODE \B
LRQ (0)
LRQ (1)
Lost
packet
LRQ (2)
Out-of-sequence (OOS) timeout period
NAK (1)
LRQ (1)
LRQ (2)
ACK (3)
LCMP (0)
LCMP (1)
ACK (3)
LCMP (2)
CDT 013.CDD
Node \A sends three LRQs to node \B. Node \B receives LRQ sequence number 0 and
LRQ sequence number 2 but does not receive LRQ sequence number 1. Node \B
starts its out-of-sequence (OOS) timer as soon as LRQ sequence number 2 is received
out of order. When the OOS timeout period has been reached, node \B sends NAK
sequence number 1 to notify node \A that it has not received LRQ sequence number 1.
Node \A then resends its message starting at LRQ sequence number 1.
Node \B sends ACK sequence number 3 to positively acknowledge LRQ sequence
number 0, LRQ sequence number 1, and LRQ sequence number 2; and it then
responds to each LRQ with an LCMP. Node \A acknowledges the receipt of node \B’s
LCMPs by sending ACK sequence number 3.
Expand Configuration and Management Manual—523347-008
18 -18
Example of End-to-End Protocol Packet Exchanges
Subsystem Description
If node \B did not acknowledge node \A’s ENQ, node \A would continue sending ENQs
until it reached its Level 4 retry limit or until node \B acknowledged the ENQ, whichever
came first.
Note. The default OOS timeout is 300 (3 seconds). The OOS timeout can be controlled with
the Expand SCF ALTER PATH command or the WAN subsystem SCF ALTER DEVICE
command. You can control the Expand subsystem’s retry limit by setting the L4RETRIES
modifier. This modifier is explained in Section 17, Expand Modifiers.
Data Exchange With Lost Acknowledgment
Figure 18-5 shows a data exchange in which messages are received successfully but
the recipient’s acknowledgment is not received by the sender. This problem is usually
caused by network congestion, or by an Expand Level 4 timeout period that is too
short, and is indicated by a large number of ENQs on the SCF STATS display.
Figure 18-5. Lost Acknowledgment
NODE \A
NODE \B
LRQ (0)
LRQ (1)
LRQ (2)
Lost packet
ACK (3)
(L4TIMEOUT)
ENQ (3)
ACK (3)
LCMP (0)
LCMP (1)
ACK (3)
LCMP (2)
CDT 035.CDD
Node \A sends three LRQs to node \B. Node \B sends ACK sequence number 3 to
acknowledge all three LRQs. Node \A does not receive an acknowledgment within the
Expand Level 4 timeout period, so it sends an ENQ sequence number 3 to node \B.
The ENQ sequence number 3 indicates to node \B that node \A has sent LRQ
sequence numbers 0 through 2.
Expand Configuration and Management Manual—523347-008
18 -19
Example of End-to-End Protocol Packet Exchanges
Subsystem Description
Node \B receives the ENQ, responds by resending ACK sequence number 3 to
acknowledge the three LRQs, and then sends an LCMP in response to each LRQ.
Node \A acknowledges node \B’s LCMPs with ACK sequence number 3.
If node \B did not acknowledge node \A’s ENQ, node A would continue to send ENQs
until it reached its Level 4 retry limit or until node \B acknowledged the ENQ.
Data Exchange With Buffer Pool Failure
Figure 18-6 illustrates a data exchange in which the destination node is unable to
allocate sufficient buffer space to accept the sending node’s request. This problem is
usually caused by insufficient buffer pool space and is indicated by pool failures in the
SCF STATS display.
Figure 18-6. Buffer Pool Failure
NODE \A
NODE \B
LRQ (0)
NAK (0), WAIT
LCMP(0)
(no buffer)
(to prior request
from NODE \B)
ACK (1), WAIT BIT RESET
LRQ (1)
(buffer deallocated)
LRQ (2)
LRQ (3)
ACK (4)
LCMP (0)
LCMP (1)
ACK (3)
LCMP (2)
CDT 036.CDD
Note. The OOS buffer and the buffer pool are described in Message Handling and Buffer
Allocation on page 18-38 and Message Buffering on page 18-46.
Node \A sends LRQ sequence number 0 to node \B. Because node \B is unable to
allocate buffer space for the message, it replies with NAK sequence number 0 with its
wait bit set. The wait bit indicates to node \A that a resource limitation has occurred
and that node \A should not resend its LRQ until the wait condition has cleared.
Expand Configuration and Management Manual—523347-008
18 -20
Layer 4 Send Window
Subsystem Description
Node \A looks for responses to send to node \B and sends LCMP sequence number 0.
This LCMP is a response to a prior request from node \B. When node \B acknowledges
the LCMP with ACK sequence number 1, it deallocates its buffer and releases
sufficient resources to receive node \A’s LRQ. Node \A resends its initial LRQ (which is
now assigned LRQ sequence number 1) along with two more LRQs. Node \B
acknowledges all three LRQs with ACK sequence number 4 and then responds with
three LCMPs. Node \A acknowledges node \B’s LCMPs with ACK sequence number 3.
Layer 4 Send Window
The size of the Layer 4 send window determines how many packets are sent before an
acknowledgment is required. The default value for the Layer 4 send window is 254,
allowing as many as 254 unacknowledged outstanding packets in any single end-toend connection.
Note. You can alter the size of the Layer 4 send window with the L4SENDWINDOW modifier.
This modifier is explained in Section 17, Expand Modifiers.
Expand Configuration and Management Manual—523347-008
18 -21
Routing and Time Factors
Subsystem Description
Routing and Time Factors
This subsection explains how $NCP implements its routing scheme. It describes the
following topics:
•
•
•
•
•
•
•
•
Setting Time Factors on page 18-23
Negotiating Path Time Factors on page 18-24
Best-Path Route Selection on page 18-24
Network Routing Table (NRT) and Multiple Path Table (MPT) on page 18-25
Calculating Route Time Factors on page 18-27
Routing Algorithms on page 18-28
Multi-CPU Paths on page 18-31
Multi-CPU Routing Examples on page 18-34
$NCP provides a sophisticated automatic routing scheme to ensure that a message
gets to its destination in the most efficient way possible. This most efficient way is
called the best-path route. $NCP determines the best-path route based on the time
factors (TFs) and hop counts (HCs) of available routes. $NCP maintains routing
information in the network routing table (NRT) and, for multi-CPU paths, in the
multiple path table (MPT) and reverse pairing table (RPT).
A time factor of 1 represents the best path and a time factor of 186 represents the
least-favorable path.
A path is one or more lines between two nodes.
Paths to a neighbor are called direct paths or single-hop paths. A direct path can be a
single-line path, a multi-line path, or a multi-CPU path that is made up of one or more
multi-line or single-line paths.
How the path time factor is determined depends on the type of path, as follows:
•
•
If a path consists of only one line—as in the case of single-line path—the time
factor for the path is the same as the time factor for the line. The time factor
setting, regardless of how it is set, is used directly to calculate the path’s time
factor.
If a path consists of more than one line—as in the case of a multi-line path—the
path time factor is derived from a composite of the time factors for the single lines
that make up the multi-line path. Accordingly, the path time factor can possibly
change as lines go up or down. (Note, however, that if you set PATHTF n, it sets
the path time factor directly, regardless of the line time factors and line states.)
The formula for calculating a path time factor from the line time factor is as follows
(the ROUND function rounds to the nearest integer):
PATHTF = ROUND(224000 / (224000 / LINETF1 + 224000 / LINETF2 + …))
Expand Configuration and Management Manual—523347-008
18 -22
Setting Time Factors
Subsystem Description
•
Expand’s multi-CPU paths are made up of two or more direct paths to the same
neighbor that operate in parallel. So the calculation of a multi-CPU path time factor
is done in a very similar way as the time factor for a multi-line path (where you
have parallel lines).
The time factor for a path to a remote (multi-hop) node is calculated as the sum of the
time factors for all direct (single-hop) paths that make up the path. The result is the
called the aggregate TF for the entire multi-hop path.
Setting Time Factors
The PATHTF, LINETF, SPEEDK, SPEED, and RSIZE modifiers all establish time
factors. You set these modifiers by using the ALTER LINE or the ALTER DEVICE
command, the latter of which alters the line device and is retained through a cold load.
As of G06.20, it is recommended that you use LINETF to specify priorities for individual
lines. PATHTF changes routing behavior for multi-line paths, forcing a constant time
factor rather than letting the path’s time factor be the aggregate of the time factors of
the lines that are currently operational.
For example, you can use PATHTF to set your own time factor in selecting the path, so
if you prefer to use ServerNet as the best path, ATM as the second best path, and FOX
as the third best path, then you would set the PATHTF as 1 for ServerNet, 2 for ATM, 3
for FOX, and a value greater than 3 for all other paths. The smaller the number, the
more desirable the path. The range is 0 through 186.
The order of selection for the various time factor parameters is as follows (highest to
lowest): PATHTF, LINETF, SPEEDK, SPEED, or RSIZE. One of these time-factor
parameters must be set, else the line handler will display a configuration error.
PATHTF n has a range of 0 to 186 to designate the time factor in selecting the best
path to other nodes. A smaller number indicates a more desirable path for routing.
PATHTF overrides all other parameters in calculating the time factor for the path. When
PATHTF is set for a multi-line path, the line state and number of lines in the path are
ignored and the PATHTF setting is a constant value assigned to the time factor for the
path. PATHTF used on a single-line path device is the same as using LINETF on the
line device.
LINETF n has a range of 0 to 186 to designate the line time factor in selecting the best
path to other nodes in the network. A smaller number indicates a more desirable path
for routing. LINETF overrides the RSIZE, SPEED, or SPEEDK parameters in
calculating the time factor for the line.
SPEEDK n, which was the recommended setting before G06.20, can still be used but
now behaves differently and is no longer recommended. If you use this setting, every
line equivalent to or faster than a FOX line has a time factor of 1.
SPEED n provides a way of creating the time factor, and has a maximum value of
244,000. Its use is no longer recommended.
Expand Configuration and Management Manual—523347-008
18 -23
Negotiating Path Time Factors
Subsystem Description
RSIZE n has a range of 0 to 186 to designate the line time factor in selecting the best
path to other nodes in the network. A smaller number indicates a more desirable path
for routing.
As always, the actual time factor used for a path between two immediate neighbors is
negotiated and the larger of their respective calculations is used.
Time Factors and Pathchange Messages
When a line comes up, Pathchange messages are exchanged to verify and negotiate
various parameters between the line handlers on each side of the line. One of the
parameters negotiated is the line’s time factor, the larger time factor being used by
both sides.
Time Factors and Netmap Messages
Netmap messages are exchanged between the NCPs of neighboring systems to
spread network topology information. Netmap messages contain the total time factor
and number of hops from the sender to each other system in the network.
Time Factors and Line Status Messages
The EXPLH_EXPNCP_LINE_STATUS message is sent from the line handler to NCP
to report both a change in line status and various parameters of a line that has come
up, such as nextsys, time factor, and delay factor.
Negotiating Path Time Factors
During connection to a remote node, the calculated path time factors are negotiated to
the higher time factor. $NCP is informed of this negotiated time factor and updates its
NETMAP table information. This negotiated time factor is used by $NCP to calculate
the route time factor.
If a line in the path fails, $NCP updates its NETMAP table to reflect the decrease in
path bandwidth. Reactivation of the line updates the NETMAP table to reflect the
increase in bandwidth. If a communications device fails, $NCP updates its NETMAP
table to reflect the decrease in bandwidth for all lines connected to the failed
communications device. (Note, however, that if PATHTF n is used to set the time
factor, this does not apply; instead, the time factor is constant.)
Best-Path Route Selection
Although $NCP may be aware of several routes to a destination node, only a single
route is active at any one time. This single route, which is the most efficient route at a
given point in time, is called the best-path route.
$NCP uses the following criteria to select the best-path route to a specific node:
•
The route must have the lowest TF of all possible routes.
Expand Configuration and Management Manual—523347-008
18 -24
Subsystem Description
•
•
Network Routing Table (NRT) and Multiple Path
Table (MPT)
If two or more routes have the same TF, the route that has the lowest hop count
(HC)—the fewest intervening nodes—is selected. Each path between two nodes is
one hop. For example, a route that includes one passthrough node has a HC of 2;
a route that includes two passthrough nodes has an HC of 3, and so on.
If two or more routes have the same TF and HC, the first path that is operational
after the node is started is selected.
If $NCP determines that the best-path route to a destination node is a multi-CPU path,
the NRT lookup routine selects a path within the multi-CPU path that spreads the load
over all the paths in the multi-CPU path. Path selection is performed using the path’s
effective time factor (ETF). The ETF is an extension of the path TF that represents
both the speed of the path and the resources available on the path to accommodate
more traffic.
The ETF indicates the inverse proportion of traffic that should be sent over a path
compared to an unloaded path that has a TF of 1. For example, a path that has a TF of
6 reports an ETF of 12 when it is half loaded. The ratio between a path’s ETF and its
base TF is called the load factor (LF) of the path.
To compute a path’s ETF, aggregate line utilization must be determined in both
directions on the path. Information obtained by the congestion control feature, along
with information about local memory usage, is used to compute the ETF. If there has
been no recent traffic on a path, a separate extended packet called a PING message
is sent to measure the round-trip time to the neighbor node.
Network Routing Table (NRT) and Multiple Path Table (MPT)
The network routing table (NRT) resides in each processor in each node in the
network. The NRT associates each destination node with the logical device (LDEV)
number of the Expand line-handler process that is chosen to use to send messages to
that node (the best-path route). The NonStop Kernel operating system uses the NRT to
select the appropriate line LDEV for message transmission to other nodes.
The additional routing information required for multi-CPU paths is maintained in the
multiple path table (MPT). The NRT contains an entry that points to the MPT. Like the
NRT, the MPT resides in each processor in each node in the network. MPT entries are
assigned to specific multi-CPU paths by $NCP. The MPT also includes an entry called
the reverse pairing table (RPT), which contains information about Expand linehandler pairs. For more information on pairing, refer to Multi-CPU Paths on
page 18-31.
The $NCP at each node depends on the routing information it receives from neighbor
$NCPs to keep the routing information in the NRT and MPT up to date. Each node
updates its NRT and MPT as it becomes aware of changes in network status, thus
allowing message traffic to be routed correctly.
Expand Configuration and Management Manual—523347-008
18 -25
Network Routing Table (NRT) and Multiple Path
Table (MPT)
Subsystem Description
$NCP sends routing information to the $NCPs at its neighbor nodes at the following
times:
•
•
As soon as $NCP becomes aware of a change in the network, such as a line going
up or down or a node being added or deleted.
During a regular maps exchange. (Maps exchanges are described in Regular
Maps Exchanges on page 18-27.)
Immediate Network Updates
If the communications line between nodes \C and \D in Figure 18-7 were to fail, for
example, both nodes \C and \D would immediately notify the neighbor nodes \A, \B,
and \E. Nodes that are not immediate neighbors would be notified during a regular
maps exchange. This same neighbor-informing scheme is used when a
communications line becomes available or when a new node is added to the network.
For a multi-line path, the procedure is the same as that just described above, with one
exception: a line-ready or a line-not-ready condition can cause a change in a path TF
without causing a change in the best-path route. For a multi-CPU path, the procedure
is the same as that described for single-line paths.
Figure 18-7. $NCP Exchange of Network Change Information
Node \B
Node \A
Informs
Neighbor
of Failure
Informs
Neighbor
of Failure
Informs
Neighbor
of Failure
Informs
Neighbor
of Failure
Line Failure
Node \C
Node \D
Node \E
CDT 017.CDD
Expand Configuration and Management Manual—523347-008
18 -26
Calculating Route Time Factors
Subsystem Description
Regular Maps Exchanges
A maps exchange is a periodic sharing of network map information. Maps messages,
called distance vector (DV) messages, are exchanged at variable-rate intervals by
default. You can specify a fixed five-minute interval exchange by setting the
AUTOMATICMAPTIMER modifier.
Note. The AUTOMATICMAPTIMER modifier is explained in Section 6, Configuring the
Network Control Process.
Calculating Route Time Factors
A route is a sequence of one or more paths through the network. The Expand
subsystem calculates route TFs for you by adding together the TFs of all the lines,
paths, or multi-CPU paths in the route; the total is the route TF. This is the same both
types of time factor.
Figure 18-8, Sample Network With Time Factors, on page 18-27 shows a simple fivenode network. TFs are assigned to the lines between nodes. The double lines between
nodes \A and \B indicate a two-line path.
Note the route from node \A to node \D through node \B. The TF for this route is 5,
which is the total of the TFs between node \A and node \B (TF 4) and node \B and
node \D (TF 1).
Figure 18-8. Sample Network With Time Factors
Node \A
Node \B
TF 4
TF 1
TF 1
TF 1
Node \C
TF 1
Node \D
Node \E
CDT 016.CDD
Expand Configuration and Management Manual—523347-008
18 -27
Routing Algorithms
Subsystem Description
Routing Algorithms
Routing algorithms determine what and how much routing information $NCP will share
with the $NCPs at its neighbor nodes. You can select from two different routing
algorithms by setting the ALGORITHM modifier: modified split horizon (MSH) and split
horizon (SH). MSH is the default algorithm.
Note. ALGORITHM 0 specifies MSH, and ALGORITHM 1 specifies SH. The ALGORITHM
modifier is explained in Section 6, Configuring the Network Control Process.
Modified Split Horizon (MSH)
When the modified split horizon (MSH) algorithm is used, $NCP tells its neighbor
$NCP the best-path route to a destination node. If that route leads through the
neighbor being updated, $NCP tells its neighbor $NCP that no route exists to the
destination.
Figure 18-9 shows the routing information known by node \D when the MSH algorithm
has been selected. Each entry indicates the TF and HC to each node from the
perspective of node \D. For example, the best-path route from node \D to node \A by
means of node \C is 2(2) (TF 2 and HC 2). Node \C reports to node \D that no path
exists from itself to node \B because its best-path route leads through node \D.
The advantage of the MSH algorithm is its efficiency: it requires less processing time
than the SH algorithm and avoids loop routing. (Loop routing is a disadvantage of the
SH algorithm; it is explained in Split Horizon (SH) on page 18-30.)
The disadvantage of the MSH algorithm is that the network may experience temporary
discontinuity, which occurs because $NCPs are not immediately aware of alternate
paths that may exist to a destination node.
For example, suppose that the path fails between node \D and node \B. Node \D is not
aware of an alternate path, although one exists through node \C. Before node \D can
reroute traffic through node \C, the following events must occur:
•
•
•
Node \D must inform node \C of the failed path.
Node \C must update its best-path route.
Node \C must inform node \D of its new best-path route information.
Node \D may complete requests with an error 250 (all paths to the system are down)
before it receives alternate path information.
You can offset this disadvantage of the MSH algorithm by specifying the
ABORTTIMER modifier, which enables you to ensure that $NCP has an opportunity to
obtain alternate routing information before requests are completed with an error 250.
The opportunity interval is the number of minutes you have defined as the
ABORTTIMER modifier value.
Note. The ABORTTIMER modifier is explained in more detail in Section 6, Configuring the
Network Control Process.
Expand Configuration and Management Manual—523347-008
18 -28
Routing Algorithms
Subsystem Description
Figure 18-9. Routing Information With the MSH Algorithm
Node \A
Node \B
TF 4
TF 1
TF 1
TF 1
TF 1
NRT
Node \C
To
Nodes
Node \E
Node \D
\C
Via Nodes
\B
\E
\A
2 (2)
--
--
\B
--
1 (1)
--
\C
1 (1)
--
--
\E
--
--
1 (1)
CDT 018.CDD
Expand Configuration and Management Manual—523347-008
18 -29
Routing Algorithms
Subsystem Description
Split Horizon (SH)
When the split horizon (SH) algorithm is used, $NCP tells its neighbor $NCP the bestpath route or the second-best route to a destination node. If the best-path route leads
through the neighbor being updated, $NCP will tell its neighbor $NCP its second-best
route as long as that route does not lead directly through the neighbor being updated.
Figure 18-10 shows the routing information known by node \D when the SH algorithm
has been selected. Each entry indicates the TF and HC to each node from the
perspective of node \D. Notice that with the SH algorithm, node \C reports to node \D
that a path does exist from itself to node \B; this is its second-best path.
Figure 18-10. Routing Information With the SH Algorithm
Node \A
Node \B
TF 4
TF 1
TF 1
TF 1
TF 1
NRT
Node \C
Node \D
Node \E
Via Nodes
To
Nodes
\C
\B
\E
\A
2 (2)
5 (2)
--
\B
6 (3)
1 (1)
--
\C
1 (1)
6 (3)
--
\E
8 (5)
8 (5)
1 (1)
CDT 019.CDD
The advantage of the SH algorithm is that alternate paths are immediately known
(temporary discontinuity never occurs).
Expand Configuration and Management Manual—523347-008
18 -30
Multi-CPU Paths
Subsystem Description
The disadvantage of the SH algorithm is that it increases the occurrence of loop
routing, which results in excessively long routes. Loop routing most often occurs in
large, multi-ringed networks. For example, in Figure 18-10, suppose the path fails
between node \D and node \E. If a message is sent from node \A to node \E, the
Expand subsystem will attempt to reroute traffic in the following sequence:
•
•
Through nodes \B, \A, \C, and \D. This route is not usable because it uses the
failed path between nodes \D and \E.
Through nodes \C, \A, \B, and \D. This route is also not usable because it uses the
failed path between nodes \D and \E.
After these two failed rerouting attempts, the Expand subsystem will determine that the
path between nodes \D and \E has failed.
You can offset this disadvantage of the SH algorithm by specifying the
NETWORKDIAMETER modifier, which defines the maximum HC that is acceptable
between two nodes. If a route is calculated that exceeds this limit, packets are
discarded. By specifying the NETWORKDIAMETER modifier, you increase the speed
with which unreachable nodes are discovered.
Note. The NETWORKDIAMETER modifier is explained in more detail in Section 6,
Configuring the Network Control Process.
Multi-CPU Paths
To guarantee message order when a multi-CPU path is used, one Expand line-handler
process at each source node and one Expand line-handler process at each destination
node are paired; all messages between that source and destination node are sent
through this Expand line-handler pair.
Whether the source and destination nodes are regarded as a group of processors or
as a single system, and when the Expand line-handler pair is formed, depends on
whether the source and the destination nodes are neighbors.
Non-Neighbor Nodes
For non-neighbor nodes, the Expand line-handler pairs are similar to those used by
single-line and multi-line paths—they apply to each source and destination system
combination. The NRTs in all processors in the entire system point to the same path,
so global NRT updates are used. The Expand line-handler pair is established by $NCP
when the connection is first made to the remote node. The pairing is symmetrical;
messages traveling in either direction use the same Expand line-handler pair.
When $NCP initiates a connection to a non-neighbor node and the best-path route to
the node is a multi-CPU path, $NCP selects one Expand line-handler process in the
multi-CPU path and starts the connection over that Expand line-handler process. The
neighbor node directs traffic from all its processors to the Expand line-handler process
from which the connection initiation was received using information maintained in the
reverse pairing table (RPT).
Expand Configuration and Management Manual—523347-008
18 -31
Multi-CPU Paths
Subsystem Description
Neighbor Nodes
For neighbor nodes, Expand line-handler pairs apply only to each source and
destination processor combination, not to entire systems. This method allows traffic
between neighbor nodes to be distributed over all the paths in the multi-CPU path.
Message order is preserved only between processor pairs instead of between entire
systems.
$NCP does not establish Expand line-handler pairs with a neighbor node. Instead,
when the first message is sent from a processor in the source node to each processor
in the destination node, the NRT lookup routine in the source processor selects an
Expand line-handler process and saves that process in the NRT in its processor;
subsequent messages sent from the same processor in the source node to the same
processor in the destination node are sent using the same Expand line-handler
process.
When selecting an Expand line-handler process, the NRT lookup routine selects a
process that spreads the load over all the paths in the multi-CPU path. Pairing
information is not broadcast to other processors, and pairings are not symmetrical;
messages between the same two processors in the reverse direction may use a
different Expand line-handler pair.
Note. $NCP does not know which Expand line-handler processes have been paired; this
information is maintained separately in each processor in its MPT.
Load Balancing
The formation of Expand line-handler pairs can interfere with the requirement to
balance traffic over all paths in a multi-CPU path. In addition, traffic patterns can
change radically over time, causing imbalances to occur after the formation of Expand
line-handler pairs. (This is especially true for non-neighbor pairs because they tend to
be made when the multi-CPU path is first started and no traffic information is
available.) For these reasons, $NCP periodically runs a rebalancing algorithm that
reconsiders the pairings of Expand line-handler processes on each multi-CPU path. If
the load is unbalanced, $NCP changes some Expand line-handler pairs.
Multi-CPU path (superpath) rebalancing is run periodically to correct path selection as
traffic patterns change. It has three goals:
•
•
•
CPU Matching: Make sure all source/destination pairs are using a path with the
most CPU matches available (same local/remote CPU).
Load Factor Balancing: Try to make the load factors of all paths within 0.5 of each
other.
Pair Count Balancing: Spread those pairs whose traffic have no adverse impact on
load factors (LFs) over all paths.
Expand Configuration and Management Manual—523347-008
18 -32
Multi-CPU Paths
Subsystem Description
Caution. A multi-CPU rebalance can introduce a temporary disruption in the network, similar
to but in general less than that caused by an Expand path change. For that reason, it is
recommended that rebalances be limited to off-peak hours unless an imbalance is clearly
causing immediate problems.
The three goals are handled in three separate steps.
1. First, CPU matching is done for each source/destination pair by looking for line
handlers that have better CPU matches than their current owner. If more than one
path has the best match, choose the one that yields the lowest predicted loadfactor spread. The pair is moved without regard for anti-thrashing bits (see below)
or possible increase in the load-factor spread.
2. Next, the load factors are balanced. The load-factor spread is the highest load
factor minus the lowest load factor; this step tries to minimize the load factor
spread until it is less than 0.5. To do this, calculate the sensitivity of each path's
load factor to its total traffic, assuming a linear relationship between average LF
and total traffic. This is used to predict the effect on the load factors of moving
traffic from one line handler to another.
Then consider moving each pair from each other line handler to the one with the
lowest load factor, and of moving each pair from the line handler with the highest
load factor to each other line handler and predict the resulting change in load
factors.
Choose the single move that results in the lowest predicted load factor spread, put
it on the output change list, update the load factors according to the predicted
changes, and check the new load factor spread value. This is continued until the
load factor spread is less than 0.5 or no moves can be found that improve the load
factor spread.
3. Lastly, the pair counts are balanced. Use the path selection algorithm described
above with current LF information to determine the goal number of pairs for each
line handler. To prevent new line handlers with low LFs and no current pairs from
taking on more pairs than they can actually handle, those line handlers with too few
pairs have their goals reduced by half their shortfall.
Then consider moving each pair from the line handler with the highest excess pairs
to each line handler with a dearth. Choose the move that results in the lowest
predicted load-factor spread with no increase from previous efforts. If more than
one path has the same lowest load-factor spread, choose the one with the largest
pair-count shortfall. This is continued until there are no excess pairs or all possible
moves increase the load-factor spread.
A maximum of 16 moves can be put on the output change list. All of the above stop
when that count is reached. Pairs on the change list are flagged with an anti-thrashing
bit; selection of those pairs for moving is avoided during the next one rebalance.
Because rebalancing is slightly disruptive, $NCP changes Expand line-handler pairs
only at the following times:
Expand Configuration and Management Manual—523347-008
18 -33
Multi-CPU Routing Examples
Subsystem Description
•
•
•
•
When a new path comes up. (This is similar to what happens in normal paths when
a new path that has a lower TF is discovered.)
At configurable times during the day. You can use the SCF ALTER PROCESS,
AUTOREBALANCE command to specify when rebalancing should occur. Both the
time of day and the interval between rebalance attempts can be specified, allowing
you to schedule a rebalance when traffic is minimal.
Immediately. You can use the SCF RESET PROCESS command to cause an
immediate rebalance.
When a path goes down. (In this case, the rebalancing algorithm is not actually
used; instead, new connections are set up according to the current load.)
Multi-CPU Routing Examples
The routing decisions made for multi-CPU paths depend on each possible combination
of source and destination node; Figure 18-11 shows multi-CPU routing for these
combinations.
In Figure 18-11, the network includes four normal paths and two multi-CPU paths. A
multi-CPU path that consists of three paths is configured between node \B and node
\C, and a multi-CPU path that consists of two paths is configured between node \C and
node \E.
Expand Configuration and Management Manual—523347-008
18 -34
Multi-CPU Routing Examples
Subsystem Description
Figure 18-11. Network Containing Normal Paths and Multi-CPU Paths
Node \B
CPU 1
LH
Node \A
LH
PRCB
PRCA
CPU 0
CPU 2
CPU 0
CPU 1
CPU 2
CPU 3
LH
CPU 4
LH
LH
LH
Multi-CPU Path 1
Node \C
CPU 0
LH
CPU 1
LH
PRCC
Node \D
CPU 2
CPU 1
LH
LH
CPU 0
LH
CPU 3
LH
LH
CPU 2
Multi-CPU Path 2
LH
Node \F
Node \E
LH
CPU 0
LH
CPU 1
PRCF
LH
CPU 0
CPU 1
CPU 2
CPU 2
LH
CPU 3
CDT 053.CDD
Expand Configuration and Management Manual—523347-008
18 -35
Subsystem Description
Multi-CPU Routing Examples
Combination 1: Local Source Node and Neighbor
Destination Node
In this scenario, the source node is the local node and the destination node is a
neighbor; a message is sent directly from one node to the other. When the first
message destined for each processor in the neighbor node is sent, the originating
processor selects a local path to the destination node and selects a pair of Expand
line-handlers for the source and destination processor combination. Subsequent
messages from that originating processor to that destination processor use the same
path.
For example, in Figure 18-11, if the process named PRCB on node \B sends a
message to the process named PRCC on node \C and $NCP determines that multiCPU path 1 is the best-path route, the NRT in processor 0 selects the Expand linehandler process in processor 2 to transmit the message because its remote Expand
line-handler process is in the same processor as PRCC.
If PRCB (or any other process in processor 0 on node \B) sends another message to
PRCC (or any other process in processor 1 on node \C), $NCP immediately uses the
same Expand line-handler to transmit the message, this time because an Expand linehandler pairing has been initiated.
Combination 2: Local Source Node and Non-Neighbor
Destination Node
In this scenario, the source node is the local node and the destination node is a nonneighbor node. An Expand line-handler process is selected by $NCP when the
connection between the nodes is first established and all processors in the system use
this Expand line-handler process.
For example, in Figure 18-11, when $NCP on node \B first detects the existence of
node \F and determines that the best-path route to node \F is through the multi-CPU
path 1, $NCP selects an Expand line-handler process from one of those on processors
1, 2, or 4 based on the communications load and then updates the NRT in all
processors in the system. If the process named PRCB on node \B (or any other
process on node \B) sends a message to the process named PRCF on node \F (or any
other process on node \F), the NRT in processor 0 returns the Expand line-handler
process selected by $NCP, regardless of the current communications load.
Combination 3: Passthrough Traffic to a Neighbor
Destination Node
In this scenario, a message is received that is destined for a neighbor node connected
by a multi-CPU path. The message is routed to the Expand line-handler process
specified by the reverse pairing table (RPT)—if one exists. The RPT is established
when the neighbor connects to the originator of the passthrough message. The
Connect Request, Reply, and Ack messages are forward by $NCP, which sets the RPT
Expand Configuration and Management Manual—523347-008
18 -36
Subsystem Description
Multi-CPU Routing Examples
entry in all processors in the system. If a message is received from a neighbor node
and no RPT entry exists, the message is dropped.
For example, in Figure 18-11, when $NCP on node \A first detects the existence of
node \C, $NCP sends a Connect Request message to node \B which is forwarded
through multi-CPU path 1 to node \C. Later, when the Connect Ack message is sent
from node \A to node \C, $NCP on node \B sets a pointer in the RPT of all its
processors to the Expand line-handler process which received the Connect Ack
message. If PRCA on node \A sends a message to PRCC on node \C, the NRT returns
the Expand line-handler saved in the RPT when the message is received on node \B.
Combination 4: Passthrough Traffic to a Non-Neighbor
Destination Node
In this scenario, a message is received that is destined for a non-neighbor node. The
processor that receives the message simply selects a local path. Passthrough nodes
do not preserve message order, so no Expand line-handler pairing needs to be
established.
For example, in Figure 18-11, if the process named PRCA on node \A sends a
message to the process named PRCF on node \F and $NCP determines that the bestpath route is through node \B and multi-CPU path 1, the NRT on processor 3 on node
\B selects an Expand line-handler process from one of those in processors 1, 2, or 4
based on communications load when the message is received on node \B. The
Expand line-handler process for subsequent messages also is selected based on the
communications load.
Expand Configuration and Management Manual—523347-008
18 -37
Message Handling and Buffer Allocation
Subsystem Description
Message Handling and Buffer Allocation
This subsection presents a high-level overview of how data is sent and received over
an Expand network and how incoming and outgoing data is buffered. It is necessary to
understand this information to effectively configure, manage, and troubleshoot an
Expand network.
This subsection describes the following topics:
•
•
Outgoing Traffic Flow on page 18-38
Incoming Traffic Flow on page 18-42
Note. This subsection refers to modifiers that allow you to control message handling and
buffer allocation. For detailed information about these modifiers, refer to Section 17, Expand
Modifiers.
Outgoing Traffic Flow
Outgoing traffic is data that is sent from the local node to another node in the network.
Outgoing traffic includes
•
•
•
Locally originated traffic (requests and replies created by a process at the local
node that are destined for a remote node).
$NCP traffic (messages created by the local $NCP that are destined for the $NCP
at a neighboring node).
Passthrough traffic (requests or replies created at a remote node that are being
forwarded to another node).
Expand Configuration and Management Manual—523347-008
18 -38
Outgoing Traffic Flow
Subsystem Description
Locally Originated Traffic Flow
Figure 18-12 illustrates the path of a locally originated outgoing message.
Figure 18-12. Flow of an Outgoing Local Message
Queue message to
pending list for
destination node
* Security processing
* Data compression
* Message prioritization
Use memory from buffer
pool and queue message
to outgoing message list
Select highest priority
message and format
packets
Send packets
Requests
Replies
Queue message
to wait for reply list
Queue message to wait
for end-to-end ACK list
Release buffer
pool
CDT 020.CDD
When a process creates a message that is destined for a remote node, the message
system uses the NRT to route the message to the Expand line-handler process that
can most efficiently transmit the message to the destination node.
When the Expand line-handler process acquires an outgoing message from the
message system, it queues the message to its list of pending outgoing messages for
the appropriate destination node. The Expand line-handler process maintains a
different pending outgoing messages list for each destination node.
The Expand line-handler process checks the security of messages that have the
security bit set. The file system sets the security bit (LSECUREB) on certain requests
such as OPENs. Checking the security of a message involves obtaining the remote
password from the USERID file and attaching it to the outgoing message. If no remote
Expand Configuration and Management Manual—523347-008
18 -39
Outgoing Traffic Flow
Subsystem Description
password exists for the destination node, the request is completed with an error (filesystem error 48, security violation) and is not sent.
If the COMPRESS_ON modifier is set, the Expand line-handler process attempts to
compress the data in the message. When compression is configured, groups of
consecutive zeros (0), spaces, and NULLs are replaced with indicator and count
values. These values are removed and replaced with the original characters when the
message is received and decompressed by the destination Expand line-handler
process.
The Expand line-handler process prioritizes each outgoing message according to the
message’s Expand priority, which is based on the priority level of the application
process that created the message, unless the SETMODE 71 procedure is used.
SETMODE 71 can be used to assign to a message a priority level that is higher or
lower than the application process priority.
Once the security check, data compression, and message prioritization have been
performed, the Expand line-handler process queues the message to its list of outgoing
messages for the destination node. When a message is queued to the outgoing
messages list, it occupies buffer space in the Expand line-handler process buffer pool.
Note. The Expand line-handler process buffer pool is explained in Message Buffering on
page 18-46.
The Expand line-handler process formats the highest-priority message into standard
size-and-format transmission units, called packets. Messages that are too large to fit
into one packet are fragmented into as many packets as are required to contain the
entire message.
Note. The Expand line-handler process obtains packet-size information from the value
assigned to the FRAMESIZE or PATHPACKETBYTES modifier.
Packets are sent sequentially until the total message is sent. The Expand line-handler
process does not mix packets from different locally originated messages, but it may
interleave packets from locally originated messages with passthrough and $NCP
packets. ($NCP and passthrough traffic flow is discussed in $NCP and Passthrough
Traffic Flow on page 18-41.)
When all the packets that make up the total message have been sent, the Expand linehandler process queues the message to its list of unacknowledged messages. When
the Expand line-handler process receives an acknowledgment from the destination
node for the message, it processes the message differently depending on whether the
message is a request or a reply to a previous request.
If the message is a request, the Expand line-handler process queues the message to
its list of messages waiting for replies and does not release the buffer pool used by the
message. If the message is a reply, the Expand line-handler process releases the
buffer pool used by the message.
Expand Configuration and Management Manual—523347-008
18 -40
Outgoing Traffic Flow
Subsystem Description
Note. Requests are formatted into request data packets, or LRQs. Replies are formatted into
reply data packets, or LCMPs. LRQs and LCMPs are explained in Protocol Packet Types on
page 18-13.
$NCP and Passthrough Traffic Flow
Figure 18-13 illustrates the path of outgoing $NCP and passthrough traffic.
Figure 18-13. Flow of Outgoing $NCP and Passthrough Traffic
Queue packets to
$NCP/pass-through pending
list for destination node
Use memory from buffer
pool and queue packets to
outgoing $NCP/passthrough packets list
Send packets
Release buffer
pool
CDT 021.CDD
The message system uses the NRT to route passthrough packets from the incoming
Expand line-handler process (the one that received the packets) to the Expand linehandler process that can most efficiently transmit the packets to the destination
system.
Similarly, the message system uses the NRT to route locally generated $NCP packets
to the Expand line-handler process that can most efficiently transmit the message to
the $NCP at a neighboring node.
When the Expand line-handler process acquires a passthrough or $NCP packet from
the message system, it queues the packet to its list of pending $NCP/passthrough
traffic for the appropriate destination node. The Expand line-handler process maintains
a different pending $NCP/passthrough traffic list for each path.
The Expand line-handler process moves passthrough and $NCP packets from its list of
pending $NCP/passthrough traffic to its list of outgoing $NCP/passthrough traffic.
Expand Configuration and Management Manual—523347-008
18 -41
Incoming Traffic Flow
Subsystem Description
When passthrough and $NCP traffic is queued to the outgoing list, it occupies buffer
space in the Expand line-handler process buffer pool.
$NCP formats $NCP messages into packets before sending them to the appropriate
Expand line-handler process for transmission. Passthrough traffic is already in the form
of packets; it is not reassembled into messages before being forwarded to the
destination node.
Note. $NCP obtains packet size information from the value assigned to the network control
process FRAMESIZE modifier.
When they are transmitted, $NCP and passthrough packets are given precedence over
locally originated traffic and may be interleaved with packets from locally originated
messages.
After $NCP or passthrough packets have been sent, the Expand line-handler process
releases the buffer pool used by the packets.
Note. The Expand line-handler process does not require an end-to-end (Layer 4)
acknowledgment for $NCP and passthrough packets before it releases buffer pool space. This
requirement is not necessary because $NCP and passthrough traffic do not use Layer 4
services.
Incoming Traffic Flow
Incoming traffic is data that is received from another system in the network. Incoming
traffic includes
•
•
•
Locally destined traffic (packets received from a remote node that are destined for
a process at the local node).
$NCP traffic (packets received from $NCP at a neighbor node that are destined for
$NCP at the local node).
Passthrough traffic (packets received from a remote node that are destined for
another remote node).
Figure 18-14 illustrates the paths of different types of incoming traffic.
As shown in Figure 18-14, the Expand line-handler process manages different types of
incoming packets differently. The following subsections describe each type of packet
and explain how each is processed by the Expand line-handler process.
Expand Configuration and Management Manual—523347-008
18 -42
Incoming Traffic Flow
Subsystem Description
Figure 18-14. Flow of Incoming Packets
Out-of-sequence
packet
Use OOS
buffer space
Request packet
Reply packet
Reserve memory
from buffer pool
for total message
Match reply to
request and place
in request buffer
pool space
$NCP/passthrough
packet
Use memory from
buffer pool for
packet
Route packet to
outgoing
process of local
$NCP
Check OOS buffer
for out-ofsequence
packets
Reassemble message
when all packets
are received
Requests
Replies
* Decompress data
* Checksum
* Security processing
Route message
to server and
release buffer
pool space
* Decompress data
* Checksum
Route message
to requester and
release buffer
pool space
CDT 022.CDD
Out-of-Sequence (OOS) Packets
OOS packets are destined for a process at the local system but are not received in the
same order in which they were sent. For example, if the Expand line-handler process
receives packet 3 before packet 1, it considers packet 3 to be an OOS packet. When
the Expand line-handler process receives an OOS packet, it places the packet in its
OOS buffer.
Note. The OOS buffer is used only if the first packet (which contains the message header) is
not received first. If the first packet is received first but subsequent packets are out of
sequence, packets are placed in the buffer pool and the OOS buffer is not used. The OOS
buffer is described in more detail in Line Buffer on page 18-47.
Expand Configuration and Management Manual—523347-008
18 -43
Incoming Traffic Flow
Subsystem Description
Request Packets
An incoming request packet, or an LRQ, is a fragment of a request message destined
for a process at the local node. The first LRQ includes the length of the total message,
in bytes. The Expand line-handler process reserves memory from its buffer pool for the
total message based on the length information contained in the first packet.
Note. LRQs are also described in Protocol Packet Types on page 18-13.
As the Expand line-handler process receives each packet of the request message, it
places the packet in the reserved buffer pool space. If the first packet is received out of
sequence, the Expand line-handler process places packets in the OOS buffer.
When the Expand line-handler process has received all the packets of the request
message and has reassembled the message in the reserved buffer pool space, it
decompresses the message (if the message was compressed by the sending Expand
line-handler process) and performs a message-level checksum. If packets are received
out of sequence, the Expand line-handler process retrieves them from the OOS buffer.
If the message’s security bit is set, the Expand line-handler process also checks
security.
Security-checking involves acquiring the remote password from the USERID file and
comparing it to the remote password that is attached to the incoming request message.
If the passwords do not match, an error is returned to the sender of the LRQ (the
requester). If the Safeguard product is being used, the request message is also
checked by Safeguard, and Safeguard’s response is incorporated into the message.
Once the request message is successfully processed, the message system routes the
request to the appropriate process, and the Expand line-handler process releases the
buffer pool used by the request message.
Reply Packets
An incoming reply packet, or an LCMP, is a fragment of a reply message that is a reply
to a request previously generated by a process (the requester) at the local node.
Note. LCMPs are also described in Protocol Packet Types on page 18-13.
The Expand line-handler process matches the reply to the request and places the
incoming reply packets into the buffer pool occupied by the matching request. If
packets are received out of sequence, the Expand line-handler process retrieves them
from the OOS buffer and moves them to the buffer pool space for the reply.
When the Expand line-handler process has received all the packets of the reply
message and has reassembled it, it decompresses the reply message (if the reply
message was compressed by the sending Expand line-handler process) and performs
a message-level checksum. No security-checking is performed on reply messages; all
security-checking is done on request messages.
Expand Configuration and Management Manual—523347-008
18 -44
Incoming Traffic Flow
Subsystem Description
Once the reply message is successfully processed, the message system routes the
reply message to the appropriate process, and the Expand line-handler process
releases the buffer pool used by the reply message.
$NCP and Passthrough Packets
An incoming $NCP packet is a packet received from the $NCP at a neighbor node and
destined for the $NCP of the local node. An incoming passthrough packet is a packet
received from a remote node and destined for another remote node.
When the Expand line-handler process receives a $NCP or a passthrough packet, it
buffers the packet in its buffer pool. If the packet is a passthrough packet, the Expand
line-handler process routes the packet to the outgoing Expand line-handler process
that can most efficiently transmit the packet to its destination node. If the packet is a
$NCP packet, the Expand line-handler process routes the packet to the local $NCP.
Once the packet has been routed to the appropriate process ($NCP or Expand linehandler), the Expand line-handler process releases the buffer pool used by the packet.
Note. Refer to $NCP and Passthrough Traffic Flow on page 18-41 for information about
outgoing $NCP and passthrough packet handling.
Expand Configuration and Management Manual—523347-008
18 -45
Message Buffering
Subsystem Description
Message Buffering
The previous subsection showed that Expand line-handler processes buffer incoming
and outgoing requests so that data can be transferred between processes on different
nodes. This subsection describes in greater detail the data space allocated to the
Expand line-handler process for message transfer and how you can affect the size of
that buffer space. It is necessary to understand this information before you can
effectively configure or troubleshoot an Expand network.
This subsection describes the following topics:
•
•
•
•
•
•
Global Variables on page 18-47
Stack on page 18-47
Control Blocks on page 18-47
Line Buffer on page 18-47
Buffer Pool on page 18-47
Shared Memory Area for QIO on page 18-48
Note. This subsection refers to modifiers that allow you to control message buffering. For
detailed information about these modifiers, refer to Section 17, Expand Modifiers.
Figure 18-15 illustrates the Expand line-handler process data space.
Figure 18-15. Expand Line-Handler Process Data Space
Global
Variables
Stacks
Control
Blocks
OOS
Buffer
Pool Space
Line
Buffer
Buffer
Pool
Shared Memory
Area for QIO
CDT 023.CDD
Expand Configuration and Management Manual—523347-008
18 -46
Global Variables
Subsystem Description
Global Variables
The global variables space contains the Expand subsystem software global variables.
The Expand subsystem determines how much global variables space to allocate
according to the number of lines in a path controlled by the Expand line-handler
process.
Stack
The Expand subsystem allocates 700 words to the stack.
Control Blocks
The Expand subsystem preallocates space for many data structures that are likely to
be used during normal operation.
Line Buffer
The line buffer is used to buffer incoming and outgoing messages after they have been
formatted into packets by the Expand line-handler process. The line buffer for Expandover-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler processes is
located in the Expand line-handler process data space.
Read frame buffers are used to buffer incoming messages; write frame buffers are
used to buffer outgoing messages. In most cases, the Expand subsystem allocates
enough buffer space for the maximum number of read and write frame buffers. You can
adjust this with the TXWINDOW modifier. If you are using a satellite connection (which
uses the maximum window size of 61 frames) with a FRAMESIZE modifier value of
over 512 words, the Expand subsystem automatically reduces the number of transmit
and read buffers available to fit within 64K words.
The size of each frame buffer is determined by the maximum size assigned to the
PATHBLOCKBYTES, PATHPACKETBYTES, and FRAMESIZE modifiers. Frame
buffers are a minimum of 1024 bytes and a maximum of 4095 bytes, or 9180 bytes in
the case of Expand-over-IP or Expand-over-ATM.
Note. You can also control the frame buffer size by setting the FRAMESIZE or
PATHBLOCKBYTES modifier. However, the FRAMESIZE modifier value must be the same at
each node in the network. For this reason, you must not modify the FRAMESIZE modifier
value on a per-node basis.
Buffer Pool
A buffer pool space of 1024 pages (2 megabytes) is allocated by default. The buffer
pool is used by the Expand line-handler process to buffer incoming and outgoing
messages while they are sent and received from the line buffer. Figure 18-13,
Figure 18-14, and Figure 18-15 show when the buffer pool is used.
Expand Configuration and Management Manual—523347-008
18 -47
Shared Memory Area for QIO
Subsystem Description
The SCF attribute EXTMEMSIZE n allows you to specify the base size of extended
memory for the pool, from a default of 2 megabytes to as much as 32 megabytes.
This extra memory will be of invaluable help to applications such as the Remote
Database Facility (RDF) which in the past suffered from memory pool problems and
thus reduced performance.
Shared Memory Area for QIO
QIO is a mechanism for transferring data between processes through a shared
memory segment. QIO is used by Expand-over-IP and Expand-over-ATM line-handler
processes. The Expand-over-IP line-handler process uses QIO to transfer data to its
associated NonStop TCP/IP process. The Expand-over-ATM line-handler process uses
QIO to transfer data to its associated ATM line.
Note. QIO memory is not the same as Extended Memory. Expand-over-ATM and Expandover-IP have both QIO and Extended Memory requirements.
The QIO subsystem has been enhanced as of G06.17 to allow you to have more
control over certain aspects of memory management. You can now configure QIO to
run in the Kseg2 memory segment and you can also control where QIO runs in the flat
memory segment. Configuring QIO to run in Kseg2 can improve performance for
Parallel Library TCP/IP and NonStop TCP/IPv6 but also imposes constraints that affect
all QIO clients (including Parallel Library TCP/IP and NonStop TCP/IPv6). As
discussed in the QIO Configuration and Management Manual, you must consider these
constraints as well as a variety of other factors before changing the default QIO
configuration.
Some of the constraints affecting Parallel Library TCP/IP and NonStop TCP/IPv6 (as
well as other QIO clients) include the reduction of QIO memory space to 128 MB when
QIO is moved to Kseg2. This restriction impacts the number of LIFs that you can
configure on your system because LIFs use QIO memory. This restriction also impacts
the number of sockets that can be opened because open sockets use QIO memory as
well. Therefore, 128 MB may not be sufficient for your Parallel Library TCP/IP, NonStop
TCP/IPv6, or other QIO client needs.
Note. The default configuration for the QIO subsystem has not changed.
Whether you use the default QIO configuration or one of the newly-supported custom
configurations, you do not need to change anything in Parallel Library TCP/IP or NonStop
TCP/IPv6; all changes are made in the QIO subsystem.
For information about the QIO subsystem, refer to the QIO Configuration and
Management Manual.
Expand Configuration and Management Manual—523347-008
18 -48
Expand-to-NAM Interface
Subsystem Description
Expand-to-NAM Interface
This subsection describes how Expand-over-NAM, Expand-over-ServerNet, and
Expand-over-FOX line-handler processes access a network access method (NAM)
interface. The information presented in this subsection will help you effectively
configure, manage, and troubleshoot an Expand network that includes X.25, SNA,
ServerNet, or FOX connections.
Topics described in this subsection include:
•
•
•
Network Access Method (NAM) Processes on page 18-49
Connection Establishment on page 18-50
Sending and Receiving Data on page 18-52
You should be familiar with the information in Expand Line-Handler Processes on
page 18-2, Expand Subsystem and the OSI Reference Model on page 18-9, and
Message Handling and Buffer Allocation on page 18-38 before reading this subsection.
Note. This subsection refers to modifiers that allow you to control various aspects of the
Expand-to-NAM interface. For detailed information about these modifiers, refer to Section 17,
Expand Modifiers.
Network Access Method (NAM) Processes
Expand-over-NAM line-handler processes (which include Expand-over-X.25 and
Expand-over-SNA), Expand-over-ServerNet, and Expand-over-FOX line-handler
processes do not use the Data Link Layer (OSI Layer 2) services provided by the
Expand End-to-End protocol; instead, these line-handler processes use the Layer 2
services of a NAM process. The type of NAM process used depends on the type of
Expand line-handler process as follows:
•
•
•
•
Expand-over-X.25 line-handler processes use the Layer 2 services provided by an
X25AM line-handler process.
Expand-over-SNA line-handler processes use the Layer 2 services provided by an
SNAX/APN line-handler process.
Expand-over-ServerNet line-handler processes use the Layer 2 services provided
by the ServerNet monitor process, $ZZSCL.
Expand-over-FOX processes use the Layer 2 services provided by the FOX
monitor process, $ZZFOX.
Expand-over-NAM, Expand-over-ServerNet, and Expand-over-FOX line-handler
processes use the NETNAM protocol to communicate with the NAM interface of the
NAM process that provides Layer 2 services.
Expand Configuration and Management Manual—523347-008
18 -49
Connection Establishment
Subsystem Description
Connection Establishment
Figure 18-16 illustrates the events that occur when Expand-over-NAM, Expand-overServerNet, and Expand-over-FOX line-handler processes successfully establish a
connection through a NAM interface.
Figure 18-16. Expand-Over-NAM Connection Establishment
Expand linehandler process
sends bind
request
Active and Passive Connect Type
Passive Connect Type
Expand line-handler
process sends
active connect
Expand line-handler
process sends
passive connect
Connection
established
NAM receives
connect
request
Connection
established
Expand linehandler process
can send and
receive data
VST 024
Bind Requests and Subdevices
Before an Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX linehandler process can begin exchanging data with another Expand line-handler process,
it must first access a subdevice of the NAM process.
Note. If the NAM process is an X25AM line-handler process, subdevices are associated with
each line that is controlled by the X25AM line-handler process. X25AM subdevices enable
applications to communicate over a virtual circuit. An X25AM subdevice is roughly analogous
to a virtual circuit.
Expand Configuration and Management Manual—523347-008
18 -50
Connection Establishment
Subsystem Description
The Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler
process accesses a subdevice by sending a bind request to the NAM process. A bind
request is roughly equivalent to an OPEN procedure. The Expand-over-NAM, Expandover-ServerNet, or Expand-over-FOX line-handler process will continue to send bind
requests to the NAM process at regular intervals (default intervals are 60 seconds for
Expand-over-ServerNet line-handler processes, 60 seconds for Expand-over-FOX linehandler processes, and 30 seconds for Expand-over-NAM line-handler processes) until
the request is successful. There is no limit to the number of times the Expand-overNAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process can retry the
bind request.
You can control the bind timeout period by setting the Expand SCF TIMERBIND
attribute. (The TIMERBIND attribute does not correspond to an Expand modifier and
can be changed only by using the SCF interface to the Expand subsystem.)
Once the Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX linehandler process has successfully bound to a subdevice, it attempts to establish a
connection through the NAM process to a neighbor Expand line-handler process.
There are two ways the Expand-over-NAM, Expand-over-ServerNet, or Expand-overFOX line-handler process can attempt to establish a call: active connect or passive
connect.
The default connect method is active connect. You can cause the Expand-over-NAM,
Expand-over-ServerNet, or Expand-over-FOX line-handler process to use the active
connect method by specifying the CONNECTTYPE_ACTIVEANDPASSIVE modifier.
Active Connect Request
When the Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX linehandler process issues an active connect request, the NAM process attempts to
initiate a connection. If the request is successful, the Expand-over-NAM, Expand-overServerNet, or Expand-over-FOX line-handler process can begin sending and receiving
data over the connection.
If the request is not successful within a certain timeout period, the Expand-over-NAM,
Expand-over-ServerNet, or Expand-over-FOX line-handler process cancels the active
connect request and issues a passive connect request. When the NAM process
receives a passive connect request, it waits for an incoming connect request; this
waiting period allows the process to receive a connect request from a remote Expandover-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process.
If the passive connect request is not successful within the timeout period, the Expandover-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process will
issue another active connect request. The line-handler process will continue to
alternately issue active and passive connect requests until a request is successful.
The default connect timeout period is 60 seconds for Expand-over-ServerNet, 60
seconds for Expand-over-FOX, and 30 seconds for Expand-over-NAM line-handler
processes. You can control the connect timeout period by setting the Expand SCF
TIMERRECONNECT attribute. (The TIMERRECONNECT attribute does not
Expand Configuration and Management Manual—523347-008
18 -51
Sending and Receiving Data
Subsystem Description
correspond to an Expand modifier and can be changed only by using the SCF interface
to the Expand subsystem.)
Specifying the MAXRECONNECTS modifier enables you to limit the number of times
the Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler
process will attempt a connect request. If you specify the MAXRECCONNECTS
modifier, you can also control what happens after the reconnect limit has been reached
by specifying the AFTERMAXRETRIES_PASSIVE or AFTERMAXRETRIES_DOWN
modifier.
Passive Connect Request
When the Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX linehandler process issues a passive connect request, the NAM waits for an incoming
connect request. You can cause the line-handler process to use the passive connect
method by specifying the CONNECTTYPE_PASSIVE modifier.
The passive connect request is successful when the NAM process receives a connect
request within a certain timeout period. Once the passive connect request is
successful, the Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX linehandler process can begin sending and receiving data over the connection.
If the connection request is not successful within the timeout period, the Expand-overNAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process will continue
to issue passive connect requests at regular intervals until a connect request is
received.
The default connect timeout period is 60 seconds for Expand-over-ServerNet, 60
seconds for Expand-over-FOX, and 30 seconds for Expand-over-NAM line-handler
processes. You can control the connect timeout period with the Expand SCF
TIMERRECONNECT attribute. (The TIMERRECONNECT attribute does not
correspond to an Expand modifier and can be changed only by using the SCF interface
to the Expand subsystem.)
You can limit the number of times the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process will attempt a connect request by specifying
the MAXRECONNECTS modifier. If you specify MAXRECONNECTS, you can also
control what happens after the reconnect limit is reached by specifying the
AFTERMAXRETRIES_PASSIVE or AFTERMAXRETRIES_DOWN modifier.
Sending and Receiving Data
Specifying the TXWINDOW modifier enables you to control how many packets the
Expand-over-NAM, Expand-over-ServerNet, or Expand-over-FOX line-handler process
can send before receiving acknowledgment from the NAM process. You can also
control how many packets the NAM process can send to the Expand-over-NAM,
Expand-over-ServerNet, or Expand-over-FOX line-handler process before requiring
acknowledgment by specifying the RXWINDOW modifier.
Expand Configuration and Management Manual—523347-008
18 -52
Subsystem Description
Sending and Receiving Data
After a connection is established, the Expand-over-NAM, Expand-over-ServerNet, or
Expand-over-FOX line-handler process periodically probes the subdevice to which it is
bound to ensure that the line is still operational. If the line-handler process does not
receive a response to its probe within a certain timeout period, it will retry the probe a
specified number of times. If the retry limit is reached before a response is received,
the line-handler process will declare the connection inoperable.
You can set the probe frequency rate, timeout period, and retry limit using the Expand
SCF attributes TIMERINACTIVITY, TIMERPROBE, and RETRYPROBE.
Expand Configuration and Management Manual—523347-008
18 -53
Expand-to-IP Interface
Subsystem Description
Expand-to-IP Interface
This subsection describes how the Expand-over-IP line-handler process accesses an
Internet Protocol (IP) network. You should be familiar with the information presented in
this subsection before attempting to configure, manage, or troubleshoot an Expand
network that includes IP connections.
Topics discussed in this subsection include
•
•
•
•
NonStop TCP/IP Processes on page 18-54
Expand-over-IP Connection Establishment on page 18-55
Sending and Receiving Data on page 18-57
Forwarding Expand-over-IP Packets to Other Expand Line-Handler Processes on
page 18-58
Note. This subsection refers to modifiers that allow you to control various aspects of the
Expand-to-IP interface. For detailed information about these modifiers, refer to Section 17,
Expand Modifiers.
NonStop TCP/IP Processes
Expand-over-IP line-handler processes do not use the Data Link Layer (OSI Layer 2)
services of the Expand End-to-End protocol; instead, these line-handler processes use
the NETIP protocol at Layer 2 to communicate with a NonStop TCP/IP, Parallel Library
TCP/IP (TCPSAM), or NonStop TCP/IPv6 (TCP6SAM) process. The QIO mechanism
is used to transfer data between the Expand-over-IP line-handler process and its
associated NonStop TCP/IP, TCPSAM, or TCP6SAM process.
Note. Because the QIO mechanism involves data sharing, the Expand-over-IP line-handler
process and its associated NonStop TCP/IP process must reside in the same processor pair.
However, the Parallel Library TCP/IP architecture removes this restriction so when either the
Parallel Library TCP/IP or NonStop TCP/IPv6 subsystems are used for TCP/IP connectivity,
the Expand-over-IP line-handler process does not need to reside in the same processor pair as
the TCPSAM and TCP6SAM processes.
NonStop TCP/IP, TCPSAM, and TCP6SAM processes provide a Guardian file-system
interface to the Transmission Control Protocol (TCP) and the User Datagram Protocol
(UDP), as well as raw (direct) access to the Internet Protocol (IP). (However, rawsocket support is limited with the Parallel Library TCP/IP and NonStop TCP/IPv6
subsystems. See the TCP/IP and TCP/IPv6 Programming Manual for information
about raw-socket programming limitations. (The limitations documented in the TCP/IP
and TCP/IPv6 Programming Manual apply to Parallel Library TCP/IP as well.)) The
Expand-over-IP line-handler process uses the UDP services provided by the TCP/IP
subsystem to transmit data across an IP network. UDP is a minimal datagram protocol
Expand Configuration and Management Manual—523347-008
18 -54
Subsystem Description
Expand-over-IP Connection Establishment
that provides a mechanism for identifying the ultimate destination in a host, such as an
application program or other high-level process.
Note. The Expand End-to-End protocol already provides the sequencing, error-recovery, and
congestion control functions that a reliable stream transport service such as TCP/IP provides,
making it unnecessary for the Expand-to-IP interface to duplicate these functions.
Each NonStop TCP/IP process appears to an IP network as a separate host and is
associated with a separate IP address. An IP address is a 4-octet (32-bit) numeric
value identifying a particular network (network address portion) and a local host on that
network (local address portion). A NonStop TCP/IP process can be associated with
more than one IP address. There can also be more than one NonStop TCP/IP process
on the system at any one time; each process acts as a separate NonStop TCP/IP host.
Parallel Library TCP/IP and NonStop TCP/IPv6 provide a feature called single IP
which allows a single TCPSAM or TCP6SAM process to act as a single host for all 16
processors. NonStop TCP/IPv6 also provides the option of using IP version 6 (IPv6)
communications. IPv6 provides several new networking features and a longer, 128-bit
IP address.
Both TCP and UDP use a 16-bit port number to select a socket on the host. TCP and
UDP add to IP the capability of having several simultaneous sessions with a given
host. Multiple sessions are accommodated by specifying a port number, which
identifies the communications path, along with the IP address. Each end of the
communications path is assigned a port number for that session.
Expand-over-IP line-handler processes perform addressing by specifying a unique
combination of a destination IP address, destination port number, source IP address,
and source port number.
Expand-over-IP Connection Establishment
When the system is started up, the Expand-over-IP line-handler process waits for the
NonStop TCP/IP, TCPSAM, or TCP6SAM process (with which it is associated) and the
QIO Monitor process (QIOMON) to start. These processes must be running before
Expand-over-IP lines can be started. Next, the Expand-over-IP line-handler process
binds to its associated NonStop TCP/IP, TCPSAM, or TCP6SAM process.
Once the Expand-over-IP line-handler process has successfully bound to the NonStop
TCP/IP, TCPSAM, or TCP6SAM process, it attempts to establish a connection to the
remote Expand-over-IP line-handler process. There are two ways the Expand-over-IP
line-handler process can attempt to establish a connection: active connect or passive
connect.
The default connect method is active connect. You can cause the Expand-over-IP linehandler process to use the active connect method by specifying the
CONNECTTYPE_ACTIVEANDPASSIVE modifier.
Expand Configuration and Management Manual—523347-008
18 -55
Expand-over-IP Connection Establishment
Subsystem Description
Active Connect Request
When the Expand-over-IP line-handler process issues an active connect request, it
attempts to initiate a connection by sending a Connect Command frame to the remote
Expand-over-IP line-handler process.
Note. Because UDP is a connectionless protocol, there is no actual connection to the remote
Expand-over-IP line-handler process.
When the remote Expand-over-IP line-handler process receives the Connect
Command frame, it responds with a Connect Response frame. When the response is
received, the local Expand-over-IP line-handler process considers the line to be up.
Various path parameters are then exchanged with the remote Expand-over-IP linehandler process.
If the local Expand-over-IP line-handler process does not receive a response within the
timeout period, it sends another Connect Command frame. It will continue to send
Connect Command frames indefinitely until a response is received.
The default connect timeout period is 60 seconds. You can alter the connect timeout
period with the Expand SCF TIMERRECONNECT attribute. (The TIMERRECONNECT
attribute does not correspond to an Expand modifier and can be changed only by using
the SCF interface to the Expand subsystem.)
You can limit the number of times the Expand-over-IP line-handler process will send a
Connect Command frame by specifying the MAXRECONNECTS modifier. If you
specify MAXRECONNECTS, you can also control what happens after the reconnect
limit has been reached by specifying the AFTERMAXRETRIES_PASSIVE or
AFTERMAXRETRIES_DOWN modifier.
Passive Connect Request
When the Expand-over-IP line-handler process issues a passive connect request, it
waits for an incoming Connect Command frame from the remote Expand-over-IP linehandler process. You can cause the Expand-over-IP line-handler process to use the
passive connect method by specifying the CONNECTTYPE_PASSIVE modifier.
Note. Because UDP is a connectionless protocol, there is no actual connection to the remote
Expand-over-IP line-handler process.
The passive connect request is successful when the Expand-over-IP line-handler
process receives a Connect Command within the connect timeout period. Once the
passive connect request is successful, the local Expand-over-IP line-handler process
considers the line to be up. Various path parameters are then exchanged with the
remote Expand-over-IP line-handler process.
If the connection request is not successful within the timeout period, the Expand-overIP line-handler process will continue to issue passive connect requests at regular
intervals until a Connect Command frame is received.
Expand Configuration and Management Manual—523347-008
18 -56
Sending and Receiving Data
Subsystem Description
The default connect timeout period is 60 seconds. You can alter the connect timeout
period with the Expand SCF TIMERRECONNECT attribute. (The TIMERRECONNECT
attribute does not correspond to an Expand modifier and can therefore be changed
only by using the SCF interface to the Expand subsystem.)
You can limit the number of times the Expand-over-IP line-handler process will send a
Connect Command frame by specifying the MAXRECONNECTS modifier. If you
specify MAXRECONNECTS, you can also control what happens after the reconnect
limit has been reached by specifying the AFTERMAXRETRIES_PASSIVE or
AFTERMAXRETRIES_DOWN modifier.
Sending and Receiving Data
Once a connection has been established, the local and remote Expand-over-IP linehandler processes communicate through their associated NonStop TCP/IP, TCPSAM,
or TCP6SAM processes using the QIO mechanism. You can control how many packets
the Expand-over-IP line-handler process can send to the NonStop TCP/IP process
before waiting for a reply by specifying the TXWINDOW modifier.
Note. The RXWINDOW modifier is meaningless for Expand-over-IP connections but is
provided to maintain commonality among the different line types. Because the Expand-over-IP
line-handler process uses QIO to communicate with the NonStop TCP/IP process and the
Parallel Library TCP/IP and NonStop TCP/IPv6 processes, the Expand-over-IP line-handler
process must read all the messages on its receive queue at one time; it cannot limit the
number of messages read to the RXWINDOW modifier value because of QIO limitations.
To detect loss of connection through the IP network, the Expand-over-IP line-handler
process sends a Probe message to the remote Expand-over-IP line-handler process at
periodic intervals of inactivity.
If the Expand-over-IP line-handler process does not receive a response to its Probe
message, it will consider the line down after exceeding the maximum number of Probe
message retries.
The default inactivity interval (the amount of time the Expand-over-IP line-handler
process will wait before sending a Probe message to the remote Expand-over-IP linehandler process) is 60 seconds. You can alter the inactivity interval with the Expand
SCF TIMERPROBE attribute.
The default number of Probe messages retries is 3. You can control the number of
times the Expand-over-IP line-handler process will retry Probe messages with the
Expand SCF RETRYPROBE attribute.
Expand Configuration and Management Manual—523347-008
18 -57
Forwarding Expand-over-IP Packets to Other
Expand Line-Handler Processes
Subsystem Description
Forwarding Expand-over-IP Packets to Other Expand LineHandler Processes
Packets received by an Expand-over-IP line-handler process can be forwarded to
another type of Expand line-handler process, either on the same processor or on a
different processor. Packet forwarding is performed via the message system; this
allows servers without Expand-over-IP line-handler processes and pre-D40 systems to
access an IP network.
Figure 18-17 illustrates the flow of packets between two applications, one of which is
running an Expand-over-IP line-handler process and one of which is not. In the figure,
Expand-over-IP line-handler processes are running on nodes 1 and 2.
Figure 18-17. Expand-Over-IP Packet Forwarding
Node 1
Application
Message System
Expand LineHandler Process
Node 2
TCP/IP Process
IP
Network
Message System
Expand
Line-Handler
Process
Expand
Line-Handler
Process
Node 3
Application
TCP/IP Process
Message System
DirectConnect
Connection
Expand
Line-Handler
Process
CDT 034.CDD
Expand Configuration and Management Manual—523347-008
18 -58
Subsystem Description
Expand-to-ATM Interface
Expand-to-ATM Interface
This subsection describes how the Expand-over-ATM line-handler process accesses
an Asynchronous Transfer Mode (ATM) network. You should be familiar with the
information presented in this subsection before attempting to configure, manage, or
troubleshoot an Expand network that includes ATM connections.
Topics discussed in this subsection include:
•
•
•
•
ATM Subsystem on page 18-59
Expand-over-ATM Connection Establishment on page 18-60
Sending and Receiving Data on page 18-62
Forwarding Expand-over-ATM Packets to Other Expand Line-Handler Processes
on page 18-63
Note. This subsection refers to modifiers that allow you to control various aspects of the
Expand-to-ATM interface. For detailed information about these modifiers, refer to Section 17,
Expand Modifiers.
ATM Subsystem
Expand-over-ATM line-handler processes do not use the Data Link Layer (OSI Layer
2) services of the Expand End-to-End protocol; instead, these line-handler processes
communicate with the ATM subsystem. The QIO mechanism is used to transfer data
between the Expand-over-ATM line-handler process and the ATM subsystem.
The ATM subsystem, which is HP’s implementation of the ATM protocol, consists of
hardware and software components that reside on a NonStop S-series server. The
ATM 3 ServerNet adapter (ATM3SA) provides one bidirectional full-duplex ATM OC3
port for connection to the User-Network Interface (UNI). The UNI is an interface point
between ATM end users and a private ATM switch, or between a private ATM switch
and the public carrier ATM network. The Expand-over-ATM line-handler process uses
the services provided by the ATM subsystem to transmit data across an ATM network.
Each ATM3SA is described by a LINE object that represents the ATM line or link
connected to the ATM3SA. Permanent virtual circuits (PVCs), switched virtual
circuits (SVCs), and ATMSAP connections through the SLSA subsystem can be
configured for an ATM line.
PVC Connections
A PVC is a permanently established virtual circuit. Each PVC is associated with a PVC
name during ATM subsystem configuration. A PVC is described by the PVC object,
which is subordinate to the LINE object.
An Expand-over-ATM line-handler process that uses a PVC connection performs
addressing by specifying a PVC name.
Expand Configuration and Management Manual—523347-008
18-59
Subsystem Description
Expand-over-ATM Connection Establishment
SVC Connections
An SVC is a dynamically established virtual circuit. Each SVC is automatically
assigned an SVC name by the ATM3SA when the circuit is established. An SVC is
described by the SVC object, which is subordinate to the LINE object.
An Expand-over-ATM line-handler process that uses an SVC connection performs
addressing by specifying the following information:
•
•
The ATM address configured for the ATM line used by the remote Expand-overATM line-handler process.
The selector bytes for the ATM lines used by the Expand-over-ATM line-handler
processes on both the local and remote systems.
An ATM line is associated with a 20-byte hexadecimal ATM address. The last
(rightmost) byte of the ATM address is called the selector byte. The selector byte is
used by the ATM subsystem to direct incoming call requests to the correct ATM
subsystem client. An SVC is established when the system with the higher system
number sends an SVC call request to the system with the lower system number.
Note. Selector bytes must be coordinated among ATM clients using the same ATM line.
ATMSAP Connections
The SLSA ATM protocol direct service access point (ATMSAP) connection offers an
ATM Native Mode network interconnect support similar to that offered by the PVC
object within the ATM subsystem. Expand issues native mode frames directly to the
ATM product via a LIF associated with an ATMSAP object.
An ATMSAP object can be configured to interface to a permanent virtual circuit (PVC)
object. A LIF object must be associated with the ATMSAP object in order to provide
host access to the ATMSAP object. A PVC connection provides a static permanent
virtual circuit. A PVC is defined with a VCC attribute for the ATMSAP. The VCC is
comprised of a VPI, VCI pair.
LIF objects are associated with either a CIP object, a LEC object, or an ATMSAP
object. No objects can be configured subordinate to an ATMSAP object.
Expand-over-ATM Connection Establishment
When the system is started up, the Expand-over-ATM line-handler process waits for
the ATM line it will use and the QIO Monitor process (QIOMON) to start. The ATM line
and the QIOMON process must be running before Expand-over-ATM lines can be
started. Next, the Expand-over-ATM line-handler process binds to the ATM subsystem.
Once the Expand-over-ATM line-handler process has successfully bound to the ATM
line, it attempts to establish a connection to the remote Expand-over-ATM line-handler
process. There are two ways the Expand-over-ATM line-handler process can attempt
to establish a connection: active connect or passive connect.
Expand Configuration and Management Manual—523347-008
18-60
Subsystem Description
Expand-over-ATM Connection Establishment
The default connect method is active connect. You can cause the Expand-over-ATM
line-handler process to use the active connect method by specifying the
CONNECTTYPE_ACTIVEANDPASSIVE modifier.
Active Connect Request
When the Expand-over-ATM line-handler process issues an active connect request,
it attempts to initiate a connection by sending a Connect Command frame to the
remote Expand-over-ATM line-handler process.
When the remote Expand-over-ATM line-handler process receives the Connect
Command frame, it responds with a Connect Response frame. When the response is
received, the local Expand-over-ATM line-handler process considers the line to be up.
Various path parameters are then exchanged with the remote Expand-over-ATM linehandler process.
If the local Expand-over-ATM line-handler process does not receive a response within
the timeout period, it sends another Connect Command frame. It will continue to send
Connect Command frames indefinitely until a response is received.
The default connect timeout period is 60 seconds. You can alter the connect timeout
period with the Expand SCF TIMERRECONNECT attribute. (The TIMERRECONNECT
attribute does not correspond to an Expand modifier and can be changed only by using
the SCF interface to the Expand subsystem.)
You can limit the number of times the Expand-over-ATM line-handler process will send
a Connect Command frame by specifying the MAXRECONNECTS modifier. If you
specify MAXRECONNECTS, you can also control what happens after the reconnect
limit has been reached by specifying the AFTERMAXRETRIES_PASSIVE or
AFTERMAXRETRIES_DOWN modifier.
Passive Connect Request
When the Expand-over-ATM line-handler process issues a passive connect request,
it waits for an incoming Connect Command frame from the remote Expand-over-ATM
line-handler process. You can cause the Expand-over-ATM line-handler process to use
the passive connect method by specifying the CONNECTTYPE_PASSIVE modifier.
The passive connect request is successful when the Expand-over-ATM line-handler
process receives a Connect Command within the connect timeout period. Once the
passive connect request is successful, the local Expand-over-ATM line-handler
process considers the line to be up. Various path parameters are then exchanged with
the remote Expand-over-ATM line-handler process.
If the connection request is not successful within the timeout period, the Expand-overATM line-handler process will continue to issue passive connect requests at regular
intervals until a Connect Command frame is received.
The default connect timeout period is 60 seconds. You can alter the connect timeout
period with the Expand SCF TIMERRECONNECT attribute. (The TIMERRECONNECT
Expand Configuration and Management Manual—523347-008
18-61
Subsystem Description
Sending and Receiving Data
attribute does not correspond to an Expand modifier and can therefore be changed
only by using the SCF interface to the Expand subsystem.)
You can limit the number of times the Expand-over-ATM line-handler process will send
a Connect Command frame by specifying the MAXRECONNECTS modifier. If you
specify MAXRECONNECTS, you can also control what happens after the reconnect
limit has been reached by specifying the AFTERMAXRETRIES_PASSIVE or
AFTERMAXRETRIES_DOWN modifier.
Sending and Receiving Data
Once a connection has been established, the local and remote Expand-over-ATM linehandler processes communicate through their associated ATM lines using the QIO
mechanism. You can control how many packets the Expand-over-ATM line-handler
process can send to the ATM line before waiting for a reply by specifying the
TXWINDOW modifier.
Note. The RXWINDOW modifier is meaningless for Expand-over-ATM connections but is
provided to maintain commonality among the different line types. Because the Expand-overATM line-handler process uses QIO to communicate with the ATM line, the Expand-over-ATM
line-handler process must read all the messages on its receive queue at one time; it cannot
limit the number of messages read to the RXWINDOW modifier value because of QIO
limitations.
To detect loss of connection through the ATM network, the Expand-over-ATM linehandler process sends a Probe message to the remote Expand-over-ATM line-handler
process at periodic intervals of inactivity.
If the Expand-over-ATM line-handler process does not receive a response to its Probe
message, it will consider the line down after exceeding the maximum number of Probe
message retries.
The default inactivity interval (the amount of time the Expand-over-ATM line-handler
process will wait before sending a Probe message to the remote Expand-over-ATM
line-handler process) is 60 seconds. You can alter the inactivity interval with the
Expand SCF TIMERPROBE attribute.
The default number of Probe messages retries is 3. You can control the number of
times the Expand-over-ATM line-handler process will retry Probe messages with the
Expand SCF RETRYPROBE attribute.
Expand Configuration and Management Manual—523347-008
18-62
Subsystem Description
Forwarding Expand-over-ATM Packets to Other
Expand Line-Handler Processes
Forwarding Expand-over-ATM Packets to Other Expand LineHandler Processes
Packets received by an Expand-over-ATM line-handler process can be forwarded to
another type of Expand line-handler process, either on the same processor or on a
different processor. Packet forwarding is performed via the message system; this
allows servers without Expand-over-ATM line-handler processes to access an ATM
network. Figure 18-18 illustrates the flow of packets between two applications, one of
which is running an Expand-over-ATM line-handler process and one of which is not. In
the figure, Expand-over-ATM line-handler processes are running on nodes 1 and 2.
Figure 18-18. Expand-Over-ATM Packet Forwarding
Node 1
Application
Message System
Expand LineHandler Process
Node 2
ATM Subsystem
Message System
Expand
Line-Handler
Process
Expand
Line-Handler
Process
Node 3
Application
ATM Network
ATM Subsystem
Message System
DirectConnect
Connection
Expand LineHandler
Process
CDT 057.CDD
Expand Configuration and Management Manual—523347-008
18-63
Subsystem Description
Multipacket Frame Feature
Multipacket Frame Feature
The multipacket frame feature is a performance enhancement designed to increase
throughput and processor efficiency on all connection types. This subsection briefly
describes how the multipacket frame feature works so that you can effectively
configure and use this feature in your network.
This subsection includes the following topics:
•
•
•
•
Constructing Multipacket Frames on page 18-64
Path Initialization on page 18-66
Multipacket Frame Configuration on page 18-67
Multipacket Frame Considerations on page 18-67
Before reading this subsection, you should be familiar with the material presented in
the subsection Expand-to-NAM Interface on page 18-49.
Note. For information about the advantages and disadvantages of the multipacket frames
feature, refer to Section 3, Planning a Network Design. For information about how to configure
this feature, refer to the configuration section for the type of Expand line-handler process you
want to configure.
Constructing Multipacket Frames
When the multipacket frame feature is selected, the Expand line-handler process
combines multiple Expand packets into a single frame, called a multipacket frame,
before sending the packets to the Layer 2 protocol. How the multipacket frame is
treated by the Layer 2 protocol depends on the type of Layer 2 protocol used as
follows:
•
•
•
•
If the Layer 2 protocol is HDLC or HDLC Extended Mode, each multipacket frame
is treated as a single HDLC-type frame.
If the Layer 2 protocol is replaced by a NAM interface, such as X25AM, each
multipacket frame is treated as a single NAM message.
If the Layer 2 protocol is NETIP (the protocol used by Expand-over-IP line-handler
processes), each multipacket frame is treated as a separate UDP frame.
If the Layer 2 protocol is NETATM (the protocol used by Expand-over-ATM linehandler processes), each multipacket frame is treated as a separate ATM frame.
When the multipacket frame feature is not selected, Expand packets are sent to Layer
2 separately. How Expand packets are treated by the Layer 2 protocol depends on the
type of Layer 2 protocol used as follows:
•
If the Layer 2 protocol is HDLC or HDLC Extended Mode, each packet is treated
as a separate HDLC-type frame.
Expand Configuration and Management Manual—523347-008
18-64
Subsystem Description
•
•
•
Constructing Multipacket Frames
If the Layer 2 protocol is a NAM interface, each Expand packet is treated as a
separate NAM message.
If the Layer 2 protocol is NETIP, each Expand packet is treated as a separate UDP
frame.
If the Layer 2 protocol is NETATM, each Expand packet is treated as a separate
ATM frame.
Figure 18-19 shows how Expand packets are sent over a direct-connect (HDLC)
connection when the multipacket frame feature is not selected.
In Figure 18-19, a message is passed to a direct-connect Expand line-handler process
that requires six Expand packets. The Expand line-handler process sends each packet
in a separate HDLC-type frame.
Figure 18-19. Multipacket Frame Feature Not Selected
Message
Direct-Connect
Expand LineHandler Process
1
1
2
2
3
3
4
4
5
5
6
6
Expand
Packets
HDLC-Type
Frames
CDT 031.CDD
Figure 18-20 shows how the same message is handled when the multipacket frame
feature is selected.
Expand Configuration and Management Manual—523347-008
18-65
Subsystem Description
Path Initialization
In Figure 18-20, a message is passed to the direct-connect line-handler process with
the multipacket frame feature selected. The direct-connect line-handler process still
fragments the message into six Expand packets but now constructs one large
multipacket frame to hold all six packets. If the entire multipacket frame fits inside one
HDLC-type frame, it is sent across the line in one frame.
When constructing a multipacket frame, an Expand line-handler process continues to
add packets to the multipacket frame until the frame can no longer accommodate
another full packet or until the current number of packets in the multipacket frame is
equal to 32.
Figure 18-20. Multipacket Frame Feature Selected
Message
Direct-Connect
Expand LineHandler Process
Multipacket
Frame
1
2
3
4
5
6
1
2
3
4
5
6
HDLC-Type
Frame
CDT 032.CDD
Path Initialization
Before an Expand line-handler process at one end of a path will begin assembling
multipacket frames, the path must be initialized and the Expand line-handler processes
at both ends of the path must exchange maximum multipacket frame size information.
Individual packets are sent across the path until the path is initialized and the maximum
multipacket frame size is determined.
Multipacket frames are created from all available packets at the time the multipacket
frame is created—a timer is not used. As a result, no extra delays are incurred waiting
for additional packets.
Expand Configuration and Management Manual—523347-008
18-66
Subsystem Description
Multipacket Frame Configuration
Multipacket Frame Configuration
The FRAMESIZE modifier determines the maximum Expand packet size, in bytes,
according to the following formula:
packet_size = ( FRAMESIZE - 4 ) * 2
For example, the default value for the FRAMESIZE modifier is 132, establishing a
maximum packet size of 128 words (or 256 bytes). The FRAMESIZE modifier must be
the same value for every Expand line-handler process in the network.
Note. The multipacket frame feature does not change the requirement that all Expand linehandler processes in the network must be configured with the same value for the FRAMESIZE
modifier.
You select the multipacket frame feature and determine the maximum size of a
multipacket frame by specifying the PATHBLOCKBYTES modifier. A value of 0
disables the multipacket frame feature. The default is 0. The PATHBLOCKBYTES
modifier is explained in detail in Section 17, Expand Modifiers.
Multipacket Frame Considerations
Consider the following when configuring the multipacket frame feature:
•
•
•
In a multi-line path configuration, a line and its associated multipacket frame
remain selected for outbound traffic until the multipacket frame is full or the
maximum packet count (32) has been reached. Once a multipacket frame is full, it
is transmitted, and another line and its associated multipacket frame may be
selected. Partially filled multipacket frames are transmitted if the Expand linehandler process is momentarily inactive.
Because the multipacket frame feature is configured on a path-by-path basis, all
lines in a multi-line path will transport multipacket frames, or none will.
The value specified for the L2TIMEOUT modifier should be based on the
transmission time required for the configured PATHBLOCKBYTES modifier value
rather than the configured FRAMESIZE modifier value.
Note. See Considerations for Paths Using the Variable Packet Size Feature and the
Multipacket Frame Feature on page 18-70 for more configuration considerations.
Expand Configuration and Management Manual—523347-008
18-67
Subsystem Description
Variable Packet Size Feature
Variable Packet Size Feature
The variable packet size feature is a performance enhancement designed to improve
bulk transfers over all connection types. The variable packet size feature effectively
overrides the packet size calculated from the FRAMESIZE modifier value by allowing
you to configure a maximum packet size, which is used for both single-packet and
multipacket frames, on a per-path basis.
This subsection briefly describes how the variable packet size feature works so that
you can effectively configure and use this feature in your network. It includes the
following topics:
•
•
•
•
Variable Packet Size Configuration on page 18-68
Variable Packet Size Considerations on page 18-68
Mixing Extended and Nonextended Packets on page 18-69
Considerations for Paths Using the Variable Packet Size Feature and the
Multipacket Frame Feature on page 18-70
Variable Packet Size Configuration
You select the variable packet size feature and configure the maximum packet size for
each path in the network by specifying the PATHPACKETBYTES modifier. A value of 0
disables the variable packet size feature. The default is 1024 (bytes), which is also the
minimum size. HP recommends that you select a network-side value for
PATHPACKETBYTES and configure all servers to this value.
The PATHPACKETBYTES modifier is explained in detail in Section 17, Expand
Modifiers.
Variable Packet Size Considerations
Consider the following when configuring the variable packet size feature:
•
•
The variable packet size feature does not change the requirement that all Expand
line-handler processes in the network must be configured with the same value for
the FRAMESIZE modifier. The FRAMESIZE modifier value is used to provide
compatibility with D-series nodes running pre-D30 software and nonextended
packets that cannot be fragmented. Large packets that are destined for pre-D30
systems are fragmented at the last D30 node in the packet’s route. This ensures
compatibility with nodes that require packets to fit within the size determined by the
FRAMESIZE modifier.
The variable packet size feature cannot be used if the FRAMESIZE modifier value
is 517 or more words.
Expand Configuration and Management Manual—523347-008
18-68
Subsystem Description
•
•
•
Mixing Extended and Nonextended Packets
The variable packet size feature does not provide any benefit on paths configured
with the L4EXTPACKETS_OFF modifier, which specifies that the extended 64-byte
packet header format not be used. Nonextended frames are not fragmentable and
therefore must use the network-wide FRAMESIZE modifier value.
If a large packet encounters a path with a smaller packet size, the Expand linehandler process automatically breaks the large packet into maximum size packets
for that path. Packet fragmentation occurs as a variable size passthrough packet is
forwarded, but the next hop path has a smaller value for the PATHPACKETBYTES
modifier than does the receiving path. Packet fragmentation is performed in the
outgoing Expand line-handler process since Expand paths have no knowledge of
other paths’ configurations.
The value specified for the L2TIMEOUT modifier should be based on the
transmission time required for the configured PATHPACKETBYTES modifier value
rather than on the configured FRAMESIZE modifier value.
Mixing Extended and Nonextended Packets
In Figure 18-21, packets sent from node \A to node \B can use variable-sized packets.
Packets sent from node \B to node \C and from node \A to node \C cannot use
variable-sized packets because the L4EXTPACKETS_OFF modifier causes both
directions of data flow to use nonextended packets. Therefore, if all data is from node
\A to node \C, there is no benefit to enabling the variable packet size feature, because
nonextended packets revert to FRAMESIZE modifier-sized packets.
Figure 18-21. Mixing Extended and Nonextended Packets
Node \A
(D30)
Node \B
(D30)
Node \C
(L4EXTPACKETS_OFF)
Extended
packets
Nonextended
packets
Nonextended
packets
CDT 033.CDD
Expand Configuration and Management Manual—523347-008
18-69
Subsystem Description
Considerations for Paths Using the Variable Packet
Size Feature and the Multipacket Frame Feature
Considerations for Paths Using the Variable Packet Size Feature
and the Multipacket Frame Feature
The main difference between the variable packet size feature and the multipacket
frame feature is that the multipacket frame feature benefits users who send many small
concurrent requests, while the variable packet size feature benefits users who send
large blocks of data (bulk transfers). Packet size and multipacket frame size can be
configured and negotiated separately on each path.
With variable packet size, the Expand line-handler process should be able to send a
full variable packet inside a multipacket frame. For this reason, the value of the
PATHBLOCKBYTES modifier must be equal to or greater than the value of the
PATHPACKETBYTES modifier.
Expand Configuration and Management Manual—523347-008
18-70
Subsystem Description
Congestion Control Feature
Congestion Control Feature
Congestion in a network occurs when performance on a connection degrades due to
the saturation of a resource that is needed to deliver data from the source to the
destination. Congestion control mechanisms regulate system resources in order to
avoid network bottleneck and resource contention situations.
This subsection describes the following topics:
•
•
Congestion Control Configuration on page 18-73
Congestion Control Considerations on page 18-73
Congestion control provides improved throughput over LANs and other types of
networks that are subject to varying delays. It also improves the response time for
message transfers and provides a more efficient error-recovery mechanism. For these
reasons, HP recommends that the congestion control feature be enabled for all types
of connections.
The congestion control feature can be enabled in one direction only for each
connection. If the congestion control feature is enabled on both ends of a connection,
then it is executed for traffic in both directions. Traffic in a given direction is subject to
congestion control if the sender has congestion control enabled and the receiver
supports it. The receiver does not have to have the congestion control feature enabled
in order to support it.
Note. The congestion control feature is supported on NonStop K-series servers with D30 and
later versions of the operating system installed, or with the D20 operating system and
T9057ABS installed.
In Figure 18-22, congestion control is enabled on nodes \A and \C. Congestion control
is supported, but not enabled, on node \B. Traffic from node \A to node \B and from
node \C to node \B is subject to congestion control. Traffic from node \B to either node
\A or \C is not subject to congestion control.
Expand Configuration and Management Manual—523347-008
18-71
Subsystem Description
Congestion Control Feature
Figure 18-22. Congestion Control Not Enabled
Node \B
Node \A
Node \C
On
Off
Off
On
L4CONGCTRL_ON
L4CONGCTRL_OFF
L4CONGCTRL_ON
Congestion Control On
Congestion Control On
CDT 014.CDD
Nodes that support congestion control are compatible with nodes that do not. However,
connections between such nodes will not use congestion control. In Figure 18-23,
congestion control is enabled on nodes \A and \C but is not enabled on node \B.
Therefore, traffic from node \A or node \C to node \B is not subject to congestion
control.
Figure 18-23. Congestion Control Not Supported
Node \A
Node \B
Node \C
Off
Not
supported
Not
supported
Off
L4CONGCTRL_ON
Congestion control not
supported
L4CONGCTRL_ON
Congestion control on
Congestion control on
CDT 015.CDD
Expand Configuration and Management Manual—523347-008
18-72
Subsystem Description
Congestion Control Configuration
The congestion control feature uses end-to-end mechanisms for congestion control
and error-recovery. It does not provide any mechanisms for indicating congestion along
intermediate nodes.
Congestion Control Configuration
You select the congestion control feature by specifying the L4CONGCTRL_ON
modifier. This modifier enables the congestion control mechanism for sending packets
on a specific path. The L4CONGCTRL_OFF modifier enables you to disable the
congestion control feature. The default is L4CONGCTRL_ON for Expand-over-IP linehandler processes and L4CONGCTRL_OFF for all other Expand line-handler types.
Congestion Control Considerations
If congestion control is enabled on a node, the out-of-sequence (OOS) timer on the
receiver end of the connection should be set to 3 (the default) or greater. This timer
value is set with the OSTIMEOUT modifier. A value of 3 is appropriate for networks
with both congestion-controlled and non-congestion-controlled connections. For
networks with congestion control enabled for all connections, a greater value (such as
10) should be used for the OSTIMEOUT modifier value.
If the congestion control feature is not enabled, the Expand line-handler process uses
a static flow control window to limit the maximum number of outstanding
unacknowledged requests. There is no selective retransmission of a lost packet; all
packets are retransmitted, starting from the packet for which an acknowledgment was
not received.
If congestion is experienced on the network and packets are lost or delayed, a large
number of packets may be retransmitted, increasing the network traffic and congestion.
Since congestion is already being experienced on the network, it is likely that the
retransmission will also result in lost packets, so the whole retransmission sequence
continues, drastically decreasing throughput.
Expand Configuration and Management Manual—523347-008
18-73
Subsystem Description
Multi-CPU Feature
Multi-CPU Feature
The Expand multi-CPU feature enables you to spread the communications load over
multiple processors by connecting multiple Expand line-handler process, each in a
separate processor, between two adjacent nodes. The Expand multi-CPU feature
significantly increases the maximum throughput of an Expand path, especially for
Expand-over-IP connections, because an Expand-over-IP line-handler process and its
associated NonStop TCP/IP process must be configured in the same processor pair.
This subsection describes briefly how the Expand multi-CPU feature works so that you
can effectively configure and use this feature in your network. It includes the following:
•
•
•
Multi-CPU Paths on page 18-74
Multi-CPU Configuration on page 18-74
Multi-CPU Considerations on page 18-75
Note. For more information about Expand-over-IP line-handler processes, refer to Expand-toIP Interface on page 18-54.
Multi-CPU Paths
The multi-CPU path is the fundamental component of the Expand multi-CPU feature. A
multi-CPU path can consist of up to 16 individual Expand paths, including multi-line
paths. Each Expand line-handler process (or multi-line path) that is a member of a
multi-CPU path can be configured in a different processor.
In order to guarantee message order, one Expand line-handler process at each source
node and one Expand line-handler process at each destination node are paired; all
messages between that source and destination node are sent through this Expand
line-handler pair.
Note. For detailed information about the formation about Expand line-handler pairs, refer to
Multi-CPU Paths on page 18-31.
Multi-CPU Configuration
You configure an Expand line-handler process (or a path logical device, in the case of
a multi-line path) as member of a multi-CPU path using the SUPERPATH_ON modifier.
The SUPERPATH_OFF modifier indicates that the path is not part of a the multi-CPU
path. The default is SUPERPATH_OFF.
Note. The SUPERPATH_ON and SUPERPATH_OFF modifiers are described in detail in
Section 17, Expand Modifiers.
When a path comes up and any number of other paths to the same destination node
are already up, the action of $NCP is determined by the configuration of the new path.
If it is configured with the SUPERPATH_OFF modifier, then the new path becomes a
redundant normal path to the node. If it is configured with the SUPERPATH_ON
Expand Configuration and Management Manual—523347-008
18-74
Subsystem Description
Multi-CPU Considerations
modifier and one or more the existing paths are in a multi-CPU path, then the new path
joins the multi-CPU path. If there is no preexisting multi-CPU path, then a multi-CPU
path is created with the new path as its sole member.
When a path comes up, it negotiates its multi-CPU membership with the Expand linehandler process on the other end of the connection. Both sides of the connection must
be configured with the SUPERPATH_ON modifier or neither the local nor the remote
Expand line-handler process is considered to be a member of the multi-CPU path.
Multi-CPU Considerations
Consider the following when configuring the Expand multi-CPU feature:
•
•
•
•
•
You cannot configure more than 16 multi-CPU paths in a system.
Each multi-CPU path can consist of up to 16 paths.
Expand-over-ServerNet and Expand-over-FOX line-handler processes cannot be
part of a multi-CPU path.
Extended packets (L4EXTPACKETS_ON modifier) must be configured for Expand
line-handler processes that are part of a multi-CPU path. Not specifying extended
packets will result in an error message.
HP recommends that you specify the congestion control feature
(L4CONGCTRL_ON modifier) when configuring Expand line-handler processes
that are part of a multi-CPU path.
For more information about configuring extended packets, refer to
L4EXTPACKETS_OFF/L4EXTPACKETS_ON on page 17-14. For more information
about configuring the congestion control feature, refer to Congestion Control Feature
on page 18-71.
Expand Configuration and Management Manual—523347-008
18-75
Subsystem Description
Multi-CPU Considerations
Expand Configuration and Management Manual—523347-008
18-76
Part V. Management, Tuning,
and Troubleshooting
Part V consists the following sections, which provide management, tuning, and
troubleshooting information:
Section 19
Managing the Network
Section 20
Tuning
Section 21
Troubleshooting
Expand Configuration and Management Manual—523347-008
Part V. Management, Tuning, and Troubleshooting
Expand Configuration and Management Manual—523347-008
19
Managing the Network
This section explains how to access network resources, set up network security, and
monitor, reconfigure, and control an Expand network. Topics explained in this section
include the following:
•
•
•
•
•
Accessing Network Resources on page 19-1
Setting Up Network Security on page 19-6
Monitoring Network Activity on page 19-12
Reconfiguring the Network on page 19-19
Controlling the Network on page 19-25
Refer to the following sources for detailed information about the commands described
in this section:
•
•
•
•
•
For Expand Subsystem Control Facility (SCF) commands, refer to Section 15,
Subsystem Control Facility (SCF) Commands.
For WAN subsystem SCF commands, refer to the WAN Subsystem Configuration
and Management Manual.
For Kernel subsystem SCF commands, refer to the SCF Reference Manual for the
Kernel Subsystem.
For general SCF commands, refer to the SCF Reference Manual for G-Series
RVUs.
For a comparison of the commands provided by the SCF interface to the Expand
subsystem and the SCF interface to the WAN subsystem, refer to Appendix C,
Expand and WAN SCF Comparison.
Accessing Network Resources
This subsection describes how to use HP commands and utilities to access resources
on remote nodes in an Expand network. Topics explained in this section include the
following:
•
•
•
•
Using TACL to Manage Remote Files on page 19-2
Using Disk-File Names on page 19-2
Changing Your Default Values on page 19-3
Gaining Access to Remote Nodes on page 19-4
Expand Configuration and Management Manual—523347-008
19-1
Managing the Network
Using TACL to Manage Remote Files
Using TACL to Manage Remote Files
One of the major features of the Expand subsystem is network transparency. Because
access to the network is transparent to the user, the Expand subsystem does not
include its own network commands. This subsection describes how to use TACL
commands to manage remote files.
Note. Selected TACL commands are described in this subsection. For the syntax and reference information about all TACL commands and programs, refer to the TACL Reference Manual.
Using Disk-File Names
A disk file has a unique file name consisting of four parts, with each part separated by
a period. An example of a disk file name is
\WEST.$DISK1.SUBVOL2.FILENAME
•
•
•
•
The node name (\WEST) is the name of the node (system) where the file resides.
All nodes must be named. A node name always begins with a backslash (\) and is
limited to eight characters including the backslash. You can omit the node name if
the file resides on the current default node.
The volume name ($DISK1) is the name of the disk volume where the file resides.
The volume name must begin with a dollar sign ($), followed by one to seven
alphanumeric characters. The character following the dollar sign must be a letter.
The subvolume name (SUBVOL2) is the name of a set of files in the same disk
volume. The subvolume name can contain from one to eight alphanumeric
characters and must begin with a letter.
The file identifier (FILENAME) is the name of an individual file. The file name can
contain from one to eight alphanumeric characters and must begin with a letter.
A fully qualified file name has four parts: node name, volume name, subvolume
name, and file identifier. A partially qualified file name omits one or more of the parts.
The following are examples of partially qualified file names:
FERN.HERST
SUBVOL2.FILEA
HERST
FILENAME
The following is an example of a fully qualified file name for a file that resides on the
node named \MEL:
\MEL.$GERT.FERN.HERST
You must use a fully qualified file name when accessing a file on a remote node in your
network.
Expand Configuration and Management Manual—523347-008
19-2
Managing the Network
Changing Your Default Values
Changing Your Default Values
Each user on the system has two sets of default values: current default values and
saved default values. Saved default values are in effect when you log on. Current
default values define your present location or frame of reference in the system and
network. You can move around on the system and network by changing the current
system, volume, and subvolume defaults.
The current defaults serve another important function—when you specify a partial file
name in a command, the operating system uses your current default values to supply
missing parts of a file name. This process of adding parts to file names is known as
file-name expansion.
Note. In some situations, the TACL program does not supply the subvolume name by default.
If a volume name is immediately followed by a file identifier, the TACL program does not recognize it as a valid file name and does not supply the subvolume name. For example,
VOL1.MYFILE is not a valid name, but VOL1.SUBVOL.MYFILE and SUBVOL.MYFILE are
valid file names.
VOLUME Command
You can use the VOLUME command to change your current default node, volume, or
subvolume. The following example changes the default subvolume from $GERT.STEIN
(on your home node) to the subvolume RHALL on \LONE.$WELL:
VOLUME \LONE.$WELL.RHALL
After you enter this command, your current defaults become node \LONE, volume
$WELL, and subvolume RHALL. For example, the TACL program will expand the
partial file name SECT12 to \LONE.$WELL.RHBALL.SECT12.
To change your current subvolume from \LONE.$SAG.RHALL to \LONE.$SAG.VITA,
enter the following:
VOLUME VITA
If you enter the VOLUME command with no options, all your current defaults (node,
volume, and subvolume) are reset to your saved defaults.
SYSTEM Command
Use the SYSTEM command to change your current default node name. After you use
the SYSTEM command, you can omit the node name from the name of a file on a
remote node.
The following example sets the current default node name to \LONE:
SYSTEM \LONE
After you enter the SYSTEM \LONE command, file names you specify are assumed to
reside on node \LONE. Entering SYSTEM without specifying a node name resets the
current default node to your saved default node.
Expand Configuration and Management Manual—523347-008
19-3
Managing the Network
Gaining Access to Remote Nodes
Note. Changing the current default node does not log you onto the other node. To log onto a
node other than the one where your current TACL process is running, you must first start a
remote TACL process on that node. Logging on to a remote node is described in Starting and
Quitting a Remote TACL Process on page 19-4.
WHO Command
You can check your saved defaults using the WHO command, which shows you when
the current node, volume, or subvolume is different from your saved default.
In the following example, the local node is \MEL and the current node is a remote node
named \STU.
15> WHO
Home terminal: $Stein
TACL process: \MEL.$Z103
Primary CPU: 4 (Cyclone)
Backup CPU: 5 (TXP)
Default Segment File: $GERT.#6539
Pages allocated: 8 Pages Maximum: 1024
Bytes Used: 13364 (0%) Bytes Maximum: 1024
Current volume:
$GERT.STEIN Current system: \STU
Saved volume:
$WELL.RHALL
Userid: 6,66 Username: SUPPORT.STEIN Security: “NUNU”
Gaining Access to Remote Nodes
When NonStop S-series servers form a network using the Expand subsystem, access
to a file can be restricted to users on the local node where the file resides, or access
can be allowed for users on any node in the network.
If a file is available only to local users, you must be logged onto the local node to
access it. To log onto a node other than the one where your current TACL process is
running, you must first start a remote TACL process on that node.
Note. Safeguard can secure a file so that only specific individuals can access that file. For
more information about Safeguard, refer to the Safeguard Administrator’s Manual.
Starting and Quitting a Remote TACL Process
Note. Before you can start a TACL process on any remote node, you must be established as a
user on that node and have the same user ID and user name on both the local and remote
nodes. You must also have remote passwords set up between your local node and the remote
node. Establishing global user IDs and remote passwords is described in Setting Up Network
Security on page 19-6.
To start a TACL process on a remote node, enter a command that specifies the node,
followed by a period and the TACL program file name. For example, if your local node
Expand Configuration and Management Manual—523347-008
19-4
Managing the Network
Gaining Access to Remote Nodes
is part of a network that includes the \HERST node, you can start a TACL process on
\HERST by entering the following command:
\HERST.TACL
The TACL program returns the initial TACL prompt, and you can now log onto the
\HERST system.
A remote TACL started this way does not have a backup process. If you want the
remote TACL process to run as a process pair, enter the following command instead of
the previous command:
\HERST.TACL / NAME, CPU 1 / 2
The NonStop™ Kernel operating system assigns a name to the process pair and starts
the process in processor 1 with a backup process in processor 2.
If you do not know the processor numbers for the remote system, start the primary
process as follows:
\HERST.TACL / NAME /
Then, after you are logged on, determine the processor numbers for the remote
system and issue a BACKUPCPU command. For example:
BACKUPCPU 4
If you use the SYSTEM or VOLUME command to change your current default node,
you can start a remote TACL process without specifying the node name. For example,
the following commands start a TACL process in the node \HERST:
SYSTEM \HERST
TACL
When you are ready to quit the remote TACL process, enter the EXIT command. For
example:
5> EXIT
Are you sure you want to stop this TACL (\HERST.$Z100)?
Enter YES (or Y) to stop the remote process and return to the TACL process on your
local node. If you do not want to stop the process, enter any other character or simply
press RETURN.
Stopping a remote TACL process returns you to your local TACL process.
Running a Program on a Remote Node
When you want to run a program on the network, the program file must reside on the
node where the program is to run. You can use the explicit and implicit RUN
commands to run a program at a remote node the same way you would use these
commands to run a program on the local node.
Note. The following examples and explanations assume that the proper network access rights
are in effect.
Expand Configuration and Management Manual—523347-008
19-5
Managing the Network
Setting Up Network Security
For example, to run a program named MYPROG on the remote node \CITY using an
explicit RUN command, you would type the following command:
RUN \CITY.MYPROG
To run the same program using an implicit RUN command, you would type the
following command:
\CITY.MYPROG
When you run a program on a remote node, the default volume and subvolume names
remain in effect. Unless you use the SYSTEM command to change the default node,
the local node remains the default. If, for example, the default node was the local node
when the RUN \CITY.MYPROG command was executed, MYPROG looks for any files
it needs on the local node unless a remote node is explicitly specified in the MYPROG
program file.
You can omit the remote node name from the RUN command if you first issue a
SYSTEM command to change the default node to the remote node. In the following
example, the RUN command runs the editor in system \XYZ. The file YOURFILE is
also assumed to reside on system \XYZ.
SYSTEM \XYZ
TEDIT YOURFILE
The following command sequence runs \CITY.$DEFLT.DEFLT.MYPROG in processor 3
of the system named \CITY. The IN file is a disk file located on system \XYZ; the OUT
file is a process named $SPL running on system \SYS45.
SYSTEM \CITY
RUN MYPROG /IN \XYZ.$CAT.SUB.FNAME, OUT \SYS45.$SPL, CPU 3/
Setting Up Network Security
One of the first tasks you must perform after completing the network configuration is to
set up access to remote resources for network users. To access a process, device, or
file on a remote system, a user must have the appropriate access. Topics explained in
this section include the following:
•
•
•
•
•
•
•
Remote File Security
Remote Process Security
Remote TACL Processes
Global Remote Passwords
Subnetwork Security
Remote Super ID User
Additional Security Techniques
Expand Configuration and Management Manual—523347-008
19-6
Managing the Network
Remote File Security
Remote File Security
A user on node \WEST who wants to access a file (including a disk file, device, or
process) on a node \EAST must satisfy the following requirements:
•
•
•
The user must also be established as a user on node \EAST.
The user must have matching remote passwords established on both nodes.
To access a disk file, the user on node \WEST must have authority to access the
file on node \EAST as a remote accessor.
Each of these requirements is described in the following subsections.
Establishing Global User IDs
Each user is known to the local node by a user name and a user ID (for example,
ADMIN.BILL and 6,14). A user can access files on a remote node only if the user’s
user name and user ID are also known to the remote node.
For example, if ADMIN.BILL, who is on node \WEST, wants to access a file on remote
node \EAST, the remote node must also have a user identified as ADMIN.BILL with a
user ID of 6,14. A super group user (user ID 255,255) or a group manager at node
\EAST must add ADMIN.BILL with the TACL ADDUSER command.
You can also use the Safeguard command interpreter, SAFECOM, to define user
authentication records. Refer to the Safeguard Administrator’s Manual for information
about SAFECOM.
You can verify user names and IDs with the USERS command. As shown in the
following example, the USERS command returns the default group and user of the
user’s logon, the group user ID, the current security, and the default volume and
subvolume:
1> USERS
GROUP . USER
ADMIN .BILL
I.D. #
6,14
SECURITY
NONO
DEFAULT VOLUMEID
$PUBS.BILL
Establishing Remote Passwords
After user IDs for network users are added to relevant nodes on the network, remote
passwords must be established for each remote node. Remote passwords are
specified with the TACL REMOTEPASSWORD command or the RPASSWRD program.
For example, ADMIN.BILL (user ID 6,14) was added at nodes \WEST and \EAST. At
node \WEST, the following commands are entered to establish an allow-access remote
password to node \WEST:
logon admin.bill
remotepassword \west, shazam
Expand Configuration and Management Manual—523347-008
19-7
Managing the Network
Establishing Remote Passwords
The allow-access password for ADMIN.BILL for \WEST from all other nodes is
SHAZAM.
At node \EAST, the following commands are entered:
logon admin.bill
remotepassword \west, shazam
The user at node \EAST entered the matching password and now has remote access
to node \WEST as ADMIN.BILL.
ADMIN.BILL, logged on at node \EAST, does not have the same status at \WEST as
does the ADMIN.BILL at \WEST. Because ADMIN.BILL at \EAST is a remote accessor
of \WEST, he cannot access disk files on \WEST that are secured for local access only.
Also, if ADMIN.BILL on \EAST creates a process on \WEST that attempts to access
the home terminal on \EAST, the attempt will fail because remote passwords to allow
access from \WEST to \EAST have not been established.
For ADMIN.BILL to gain access to \EAST from \WEST, an allow-access password
must be defined for ADMIN.BILL at \EAST, matched by a request-access password at
\WEST. For example, the following is entered first at \EAST and then at \WEST:
logon admin.bill
remotepassWOrd \east, aardvark
Now users logged on as ADMIN.BILL at either node \WEST or \EAST have access to
both nodes.
Remote Password Considerations
The following considerations apply to remote passwords:
•
•
•
When matching remote passwords are established at both nodes, a user does not
need to specify the remote password to gain access to the remote node.
Furthermore, the super IDs at the various nodes in a network can set up the
appropriate allow-access and request-access passwords for all users so that the
users themselves need not be concerned with REMOTEPASSWORD commands.
When the appropriate passwords are established for a user, the user can access
files remotely without being aware of the network passwords.
The absence of an allow-access password prevents remote access by anyone
acting as that user. Thus, if MARKETING.SUE does not supply an allow-access
password, no remote user with the same user ID can access MARKETING.SUE’s
home system as MARKETING.SUE.
A remote password, once defined, remains in effect until modified by a subsequent
REMOTEPASSWORD command. The following command removes the remote
password for the system \EAST:
remotepassword \east
Expand Configuration and Management Manual—523347-008
19-8
Managing the Network
Remote Process Security
The following command removes all of the user’s remote passwords:
remotepassword
•
•
Request-access passwords and allow-access passwords can be specified at any
time. Remote access is permitted as soon as both remote passwords are defined
(provided they match).
Remote passwords are independent of local passwords. In the preceding example,
ADMIN.BILL could prevent unauthorized persons from logging on as ADMIN.BILL
by entering the following command with password LOCBILL at either system:
password locbill
Remote Process Security
The following security considerations apply to remote processes:
•
With respect to a specific node, each process in the network is either local or
remote. A process is remote to a node if it has the following characteristics:
•
•
•
The process is running on a remote node.
The process’ creator is on a remote node.
The process’ creator is node.
Therefore, a process that is running on a node can be remote with respect to that
node. These restrictions prevent a remote process from creating another process
to access a file whose security specifies local access only.
•
•
A remote process cannot suspend nor activate a local process. A remote process
cannot stop a local process, unless the stop mode of the local process is 0 (which
allows anyone to stop it).
A remote process cannot put a local process in a debug state.
Remote TACL Processes
Openers of a file are either local or remote with respect to the file. A local user is
logged onto the node on which the file resides. A remote user is logged on to a
different node in the same network.
A remote accessor of a node can become a local accessor by running a TACL process
in the remote node and logging on. For example, if remote passwords are established
so that user ADMIN.BILL at \WEST can access node \EAST, ADMIN.BILL can issue
the following commands:
1> \east.tacl
TACL 1> logon admin.bill
Password:
ADMIN.BILL is now logged on as the local ADMIN.BILL on node \EAST. Therefore,
ADMIN.BILL can access disk files on \EAST owned by ADMIN.BILL even if they are
Expand Configuration and Management Manual—523347-008
19-9
Managing the Network
Global Remote Passwords
secured “OOOO” (local owner only) along with other files that are only accessible
locally.
A remote user can be prevented from becoming a local user if the local super ID
specifies “A” (any local user) as the execute security for the TACL program file. This
prevents anyone on a remote node from starting a TACL process on the local node.
Also, a user who has the same user name as a user in another node cannot log on to
that node without knowing the local password for that user name. For example,
ADMIN.BILL on node \WEST cannot log onto node \EAST if ADMIN.BILL at \EAST has
a local password that is unknown to ADMIN.BILL at \WEST.
Global Remote Passwords
In some networks, it is not desirable for all users to have access to all nodes. However,
it is desirable to allow network access for certain users without forcing them to enter or
even know all the required REMOTEPASSWORD commands. In this case, a global
remote password can be established for these users.
At each node, a user named NET.ACCESS is established and the following commands
are issued:
LOGON NET.ACCESS
PASSWORD local-password
REMOTEPASSWORD \WEST, global-password
REMOTEPASSWORD \EAST, global-password
REMOTEPASSWORD \NYNY, global-password
.
.
.
REMOTEPASSWORD \system-n, global-password
The REMOTEPASSWORD command is used for each node on the network. The
global remote password is the same for all nodes and is known only to the system
managers. The local password is different for each node and is given only to users
who are allowed to access all nodes on the network.
Only users who know the local password can log on as NET.ACCESS. While logged
on as NET.ACCESS, these users can access remote files. For example, the following
command allows users to access remote files secured for access by NET.ACCESS:
LOGON NET.ACCESS, local-password
Subnetwork Security
In a large network, it is sometimes desirable to allow users to access some nodes but
not others. For example, users on system \SANFRAN are allowed to access nodes
\LA, \SEATTLE, and \CUPRTNO but not the \NEWYORK and \CHICAGO nodes.
In this case, the preceding examples can be extended to allow access to any number
of subnetworks (that is, any collection of individual nodes). A user such as
Expand Configuration and Management Manual—523347-008
19-10
Managing the Network
Remote Super ID User
NET.WEST is established at each node of the subnetwork, and a password scheme
like the one used in the previous example allows certain users to log on as NET.WEST.
Subnetworks implemented in this manner can overlap or include one another.
\CHICAGO might be accessible from \NEWYORK by logging on as NET.EAST, and
from \PHOENIX by logging on as NET.MIDWEST. Similarly, each system in the
network might have a user called NET.GLOBAL, who is allowed to access every other
node.
Remote Super ID User
On a single system, a super ID user can access any file. On a network, the capabilities
of the super ID can be local, global, or somewhere in between local and global as
follows:
•
•
To make the super ID exclusively a local super ID user, do not issue
REMOTEPASSWORD commands for the super ID at any node.
To make the super ID a global super ID, issue REMOTEPASSWORD commands
(as described in Global Remote Passwords on page 19-10) at every node, and
give every super ID the same password.
In this case, if a disk file is secured A, G, O, or -, a remote super ID user can still
gain access to the file by running the TACL program on that system and logging on
as the local super ID.
•
To make the super ID capabilities somewhere between a local and global super ID
user, issue REMOTEPASSWORD commands (as defined in “Global Passwords”)
at every node, but give each super ID a distinct password.
Thus, any disk file can be protected from remote access by giving it A, G, O, or security. (The remote super ID can then access files security N, C, or U.) A remote
super ID cannot log on as a local super ID user because the password for the local
super ID is unknown.
Additional Security Techniques
The Safeguard security system extends the security offered by the NonStop™ Kernel.
Safeguard does not need to be installed on every system on the network and can be
controlled by a single system. Safeguard adds the following features:
•
•
•
•
•
User aliases
File-sharing groups
Multiple group membership for users and user aliases
Further user authentication such as expiration dates, temporary suspension, and
forced password-change intervals
Authorization access to all objects including files, devices, named processes, and
disks using access control lists
Expand Configuration and Management Manual—523347-008
19-11
Managing the Network
•
•
Monitoring Network Activity
Auditing of file access, logon/logoff, and changes to security or security controls
Controlled file and process creation
Safeguard is described in the Safeguard Administrator’s Manual.
Monitoring Network Activity
Network monitoring includes gathering statistical information, checking the status of
hardware and software components, and displaying configuration values. This
subsection is organized according to the following network monitoring tasks:
•
•
•
Displaying $NCP Information
Displaying Expand Line-Handler Process Information
Starting and Stopping Tracing
Displaying $NCP Information
The SCF interfaces to the Expand and WAN subsystems provide commands that can
be used to display statistics and status information for $NCP.
Table 19-1 lists the Expand subsystem SCF commands that display $NCP information.
Table 19-1. Expand SCF Commands for $NCP Information (page 1 of 2)
SCF Command
Information Reported
INFO PROCESS $NCP, CONNECTS
Displays only the known systems that are
connected or connecting and only the entry for
which the connection is established. If the path is
a superpath, it displays all of the paths in the
superpath. This is basically a summary of the
NETMAP command showing only the connected
entries.
INFO PROCESS $NCP, DETAIL
Displays the current modifier settings for $NCP.
INFO PROCESS $NCP, LINESET
Displays the status of a selected path and the
status of the started lines that make up that path
using Super Time Factors.
INFO PROCESS $NCP, NETMAP
Displays the status of network as seen from a
specific system.
INFO PROCESS $NCP, OLDLINESET
Displays the status of a selected path and the
status of the started lines that make up that path
using the previous time-factor values.
INFO PROCESS $NCP, OLDNETMAP
Displays the status of the network as seen from
a specific system. It is displayed in the format
used prior to the introduction of Super Time
Factors.
Expand Configuration and Management Manual—523347-008
19-12
Managing the Network
Displaying $NCP Information
Table 19-1. Expand SCF Commands for $NCP Information (page 2 of 2)
SCF Command
Information Reported
INFO PROCESS $NCP, PATHSETS
Displays the NCP pathmap information similar to
the LINESET command, but displays it in a
different format. This format displays both the
line-handler LDEV and name, as well as the
other information already in the LINESET
command. It also includes all of the information
displayed in the LINESET command, which are:
entry number (this is the LINESET column),
neighbor name and node number, linehandler
LDEV, Timefactor, CPU, PIN, Status, and FileErr
Number. The new information added to this
display is the path/line name.
INFO PROCESS $NCP, RPT
Displays the information kept in the reverse
pairing table (RPT) for each multi-CPU path on
the selected system.
INFO PROCESS $NCP, SUPERPATH
Displays the paths comprising each multi-CPU
path on the system. The effective time factor
(ETF) and base time factor (TF) is displayed for
each path.
INFO PROCESS $NCP, SYSTEMS
SYSTEMS is similar to the CONNECTS
command, but displays all known systems. It
displays only the entries where a connection is
established. If no connection is established, it
displays an infinite time factor and hop count.
LISTDEV $NCP
Displays the logical device (LDEV) name and
number, primary and backup processor and
process ID, device type and subtype, configured
RSIZE value, priority level of the device, and
fully qualified program file name for $NCP.
or
LISTDEV TYPE 62
PROBE PROCESS $NCP
Displays the current paths from one or more, or
all, of the remote systems in the network to a
selected system in the network.
STATS PROCESS $NCP, LOCALFLOW
Displays aggregate packet statistics occurring at
a selected system.
STATS PROCESS $NCP, NETFLOW
Displays packet statistics that represent the
communications occurring between two selected
systems in the network.
TRACE PROCESS $NCP
Displays target-defined data items, alter trace
parameters, and end tracing.
VERSION PROCESS $NCP
Displays the version level of $NCP.
Table 19-2 lists the WAN subsystem SCF commands that display $NCP information.
Expand Configuration and Management Manual—523347-008
19-13
Managing the Network
Displaying Expand Line-Handler Process
Information
Table 19-2. WAN SCF Commands for $NCP Information
SCF Command
Information Reported
INFO DEVICE $ZZWAN.#NCP
Displays the primary and backup processors,
type, record size, object file, and profile used by
$NCP. The DETAIL option can be used to
display device-specific modifiers and modifier
values.
INFO PROFILE $ZZWAN.#ncp_profile
Displays a list of the modifiers and modifier
values contained in the profile used by $NCP.
The profile for $NCP is PEXPNCP.
STATUS DEVICE $ZZWAN.#NCP
Displays the dynamic state, logical device
(LDEV) number, and primary process
identification number (PIN) of $NCP.
Displaying Expand Line-Handler Process Information
The SCF interfaces to the Expand and WAN subsystems provide commands that
display information and status information for a selected Expand line-handler process.
Table 19-3 lists the Expand subsystem SCF commands that display general Expand
line-handler process information.
Table 19-3. Expand SCF Commands for Expand Line-Handler Processes
SCF Command
Information Reported
LISTDEV EXPAND
Displays all the configured Expand line-handler
processes on a system. Information displayed
includes the logical device name and number,
primary and backup processor and process
identification number (PIN), device type and
subtype, configured RSIZE value, priority level
of the device, and the fully qualified program file
name of the process.
or
LISTDEV TYPE 63
VERSION PROCESS $device_name
Displays the version level of the Expand linehandler process.
When you use the SCF LISTDEV command to list all the configured Expand linehandler processes, you can use the subtype displayed to identify the type of Expand
line-handler process.
Expand Configuration and Management Manual—523347-008
19-14
Managing the Network
Displaying Expand Line-Handler Process
Information
Table 19-4 lists the subtype values associated with single-line Expand line-handler
processes.
Table 19-4. Subtype Values for Single-Line Line-Handler Processes
Line Type
Subtype
Direct-connect
5
Satellite-connect
5
Expand-over-NAM
0
Expand-over-IP
0
Expand-over-ATM
0
Expand-over-ServerNet
4
Expand-over-FOX
3
Table 19-5 lists the subtype values associated with multi-line paths (path and line
logical devices).
Table 19-5. Subtype Values for Multi-Line Paths (Path and Line Logical Devices)
Line Type
Subtype
Path logical device
1
Direct-connect line logical device
6
Satellite-connect line logical device
6
Expand-over-NAM line logical device
2
Expand-over-IP line logical device
2
Expand-over-ATM line logical device
2
Table 19-6 lists the WAN subsystem SCF commands that display Expand line-handler
process information.
Table 19-6. WAN SCF Commands for Expand Line-Handler Process
Information (page 1 of 2)
SCF Command
Information Reported
INFO DEVICE $ZZWAN.#device_name
Displays the primary and backup
processors, type, record size, object file,
and profile used by a selected Expand
line-handler process. The DETAIL option
can be used to display device-specific
modifiers and modifier values.
Expand Configuration and Management Manual—523347-008
19-15
Managing the Network
Displaying Expand Line-Handler Process
Information
Table 19-6. WAN SCF Commands for Expand Line-Handler Process
Information (page 2 of 2)
SCF Command
Information Reported
INFO PROFILE $ZZWAN.#profile_name
Displays a list of the modifier values
contained in a selected Expand profile
and the device names of the Expand
line-handler processes currently using
that profile.
STATUS DEVICE $ZZWAN.#device_name
Displays the dynamic state, logical
device (LDEV) number, and primary and
backup process identification numbers
(PINs) for a selected Expand linehandler process.
Displaying Line Information
The SCF interface to the Expand subsystem provides commands that display line
(Layer 2) statistics, status information, and modifier values for a selected Expand linehandler process.
Note. The Expand subsystem SCF STATS LINE command examines Layer 2 processes and
can provide you with some basic information about line status. However, several Expand linehandler processes use the services of another process to provide Layer 2 functions:
•
•
•
For Expand-over-NAM line-handler process Layer 2 information, you should also
examine the appropriate X25AM, SNAX/APN, ServerNet, or FOX process.
For Expand-over-IP line-handler process Layer 2 information, you should also
examine the appropriate NonStop TCP/IP process.
For Expand-over-ATM line-handler process Layer 2 information, you should also
examine the appropriate Asynchronous Transfer Mode (ATM) line.
Table 19-7 lists the Expand subsystem SCF commands that can be used to display line
information.
Table 19-7. Expand SCF Commands for Line Information (page 1 of 2)
SCF Command
Information Reported
INFO LINE $device_name
Displays the current Layer 2 attribute values associated
with a selected Expand line-handler process.
Information displayed includes FRAMESIZE,
L2TIMEOUT, and other attribute values. The DETAIL
option can be used to display additional information.
Expand Configuration and Management Manual—523347-008
19-16
Managing the Network
Displaying Expand Line-Handler Process
Information
Table 19-7. Expand SCF Commands for Line Information (page 2 of 2)
SCF Command
Information Reported
STATS LINE $device_name
Displays Layer 2 statistics for a selected Expand linehandler process. Information displayed includes number
of Layer 2 frames, information frames, supervisory
frames, and unnumbered frames sent and received by
the selected Expand line-handler process.
STATUS LINE $device_name
Displays status information for a selected Expand linehandler process. Information displayed includes the
summary state of the line, primary process ID (PID),
and backup process ID (PID). For satellite-connect and
direct-connect line-handler processes, the ServerNet
wide area network (SWAN) concentrator path being
used by the line and the logical device (LDEV) number
associated with the concentrator manager (ConMgr)
process are also displayed. The DETAIL option can be
used to display additional information.
Displaying Path Information
Table 19-8 lists the Expand subsystem SCF commands that display path (Layer 3 and
Layer 4) statistics, status information, and modifier values for a selected Expand linehandler process.
Table 19-8. Expand SCF Commands for Path Information
SCF Command
Information Displayed
INFO PATH $device_name
Displays the current and default Layer 4 attribute values
for a selected Expand line-handler process. Information
displayed includes COMPRESS, NEXTSYS,
L4RETRIES, and L4TIMEOUT attribute values. The
DETAIL option can be used to display additional
information.
STATS PATH $device_name
Displays Layer 3 and 4 statistics for a selected Expand
line-handler process. Information displayed includes
statistics on extended memory, QIO, OOS, messages,
packets, queue depths, and congestion control.
STATUS PATH $device_name
Displays status information for a selected Expand linehandler process. Information displayed includes the
summary state of the path, the primary and backup
process IDs (PIDs), and the number of lines associated
with the path. The DETAIL option can be used to
display additional information, such as the logical device
(LDEV) number for lines.
Expand Configuration and Management Manual—523347-008
19-17
Managing the Network
Starting and Stopping Tracing
Starting and Stopping Tracing
The Expand subsystem SCF TRACE command allows you to select the records that
you want written to a disk file. You can then use PTrace commands to select records to
be formatted and sent to an output device.
Table 19-9 lists the Expand subsystem SCF commands that can be used to start and
stop tracing.
Table 19-9. Expand SCF Commands for Tracing
SCF Command
Action Performed
TRACE PROCESS $NCP, TO $file_name,
SELECT ALL, WRAP, RECSIZE 1024
Starts a trace of $NCP. The $file_name
parameter specifies the name of the file
to which the trace records will be
written.
TRACE PROCESS $NCP, STOP
Stops the $NCP trace.
TRACE LINE $device_name, TO $file_name,
SELECT ALL,WRAP, RECSIZE 512
Starts a trace of the specified line. The
$file_name parameter specifies the
name of the file to which the trace
records will be written.
TRACE LINE $device_name, STOP
Stops the trace of the specified line.
TRACE PATH $device_name, TO $file_name,
SELECT ALL, WRAP, RECSIZE 512
Starts a trace of a path or a single-line
Expand process. The $device_name
parameter specifies the name of the
path logical device or single-line Expand
line-handler process. The $file_name
parameter specifies the name of the file
to which the trace records will be
written.
TRACE PATH $device_name, STOP
Stops the trace of a path or a single-line
Expand line-handler process.
Refer to Section 16, Tracing for more information about the tracing process and using
PTrace to format and display trace records.
Expand Configuration and Management Manual—523347-008
19-18
Managing the Network
Reconfiguring the Network
Reconfiguring the Network
Network reconfiguration tasks include the following:
•
•
•
•
•
•
•
•
Adding and Deleting Expand Line-Handler Processes
Adding and Deleting $NCP
Changing $NCP Modifiers
Changing Expand Line-Handler Process Modifiers
Changing Profiles
Adding Nodes to the Network
Removing Nodes From the Network
Changing System Names and Numbers
Note. Configuration changes made with the SCF interface to the WAN subsystem are
permanent (they remain in effect after system loads and processor reloads); changes made
with the SCF interface to the Expand subsystem are temporary (they do not remain in effect
after system loads and processor reloads).
Adding and Deleting Expand Line-Handler Processes
The SCF interface to the WAN subsystem provides commands to add and delete
Expand line-handler processes from your system configuration. You use the WAN
subsystem SCF ADD DEVICE command to add and the SCF DELETE DEVICE
command to delete an Expand line-handler process.
Adding and Deleting $NCP
The SCF interface to the WAN subsystem provides commands to add and delete
$NCP from your system configuration. You use the WAN subsystem SCF ADD
DEVICE command to add and the SCF DELETE DEVICE command to delete $NCP.
Changing $NCP Modifiers
You can use the WAN subsystem SCF ALTER DEVICE command to change any
$NCP modifier value in the device record for $NCP.
You can use the Expand subsystem SCF ALTER PROCESS command to change the
following $NCP modifier values:
ABORTTIMER
CONNECTTIME
MAXCONNECTS
MAXTIMEOUTS
NETWORKDIAMETER
The Expand subsystem SCF ALTER PROCESS command can also be used to enable
or disable the reporting of event messages 43, 46, 48, and 49; this cannot be done
using the WAN subsystem SCF ALTER DEVICE command.
Expand Configuration and Management Manual—523347-008
19-19
Managing the Network
Changing Expand Line-Handler Process Modifiers
Changing Expand Line-Handler Process Modifiers
You can use the WAN subsystem SCF ALTER DEVICE command to change any
modifier or modifier value in the device record for a specific Expand line-handler
process.
You can use the Expand subsystem SCF ALTER LINE and ALTER PATH commands to
change certain Expand line-handler process modifiers and modifier values. Modifiers
that can be changed using the Expand SCF commands are listed in Section 17,
Expand Modifiers.
Note. Certain Expand profile modifiers do not have corresponding attribute names in Expand
SCF and therefore can be changed only by using the SCF interface to the WAN subsystem. In
addition, certain Expand SCF attributes do not correspond to Expand profile modifiers and
therefore can be changed only by using the SCF interface to the Expand subsystem. These
modifiers and attributes are listed in Section 17, Expand Modifiers.
Changing Profiles
You cannot alter a profile directly (there is no ALTER PROFILE command). However,
you can alter a modifier in a profile indirectly by deleting and reading the profile or by
using the ADD PROFILE command with the LIKE option.
For more information about profiles, refer to the WAN Subsystem Configuration and
Management Manual.
Note. When you use the ALTER DEVICE command to change a modifier or modifier value for
a specific device, you are changing the device record for that device, not the profile used by
that device. Modifiers and modifier values that are part of a device record can be different from
the modifiers and modifiers values in the profile used by a device.
Adding Nodes to the Network
This subsection explains how to add a new node (system) to the network using the
management commands described in the preceding subsections. This explanation is
presented in three steps.
Step 1: Create and start Expand line-handler processes at
adjacent nodes
Using the WAN subsystem SCF ADD DEVICE and START DEVICE commands, you
must create and then start an Expand line-handler process at the new node for each
link to an adjacent (or neighbor) node. You must also create and start an Expand linehandler process at each adjacent system for the link to the new system.
Expand Configuration and Management Manual—523347-008
19-20
Managing the Network
Adding Nodes to the Network
Creating and starting Expand line-handler processes is explained in detail in Section II,
Configuring the Expand Subsystem.
Note. Before you can start an Expand line-handler process, other processes might need to be
present and running in your system. Refer to Section II, Configuring the Expand Subsystem for
more information.
Step 2: Start the lines
Once the Expand line-handler processes are created and started, you must start the
communications lines using one of the following Expand subsystem SCF commands:
START LINE $device_name
START PATH $device_name
Note. Use the Expand subsystem SCF START PATH command for multi-line paths. The SCF
START LINE command affects the specified line and its associated path logical device; it does
not affect other lines in a multi-line path.
Step 3: Verify that the lines have started
You can verify that the lines have started by using one of the Expand subsystem SCF
commands described in Table 19-10.
Table 19-10. Expand SCF Status Commands
Command
Status Reported If the
Line Is Operational
Status Reported If the
Line Is Not Operational
STATUS LINE $device_name
STARTED
STOPPED
STATUS PATH $device_name
STARTED
STOPPED
INFO PROCESS
$NCP, LINESET
READY
NOT READY (nnn)*
*A file-system error is reported in parentheses (nnn). Refer to the Operator Messages Manual for more
information.
After the Expand lines have been started, the Expand software at the new node
automatically queries the existing nodes in the network for information about
accessible systems. The Expand subsystem then automatically selects the best path to
each accessible node and establishes end-to-end connections. The existing nodes
update their routing tables automatically.
Expand Configuration and Management Manual—523347-008
19-21
Managing the Network
Removing Nodes From the Network
Removing Nodes From the Network
This subsection explains how to remove a node from the network using the
management commands described in the preceding subsections. This explanation is
presented in two steps.
Step 1: Stop the lines
You must stop the Expand lines at the local node and the corresponding Expand lines
at adjacent (or neighbor) nodes using one of the following Expand subsystem SCF
commands:
ABORT LINE $device_name
ABORT PATH $device_name
Note. Use the Expand subsystem SCF ABORT PATH command for multi-line paths. The SCF
ABORT LINE command affects the specified line and its associated path logical device; it does
not affect other lines in the multi-line path.
Step 2: Verify that the lines have stopped
You can verify that the lines have stopped by using the one of the Expand subsystem
SCF commands described in Table 19-10.
Note. If you are permanently removing a node from the network, it is suggested that you also
remove its node (system) name and number from the network routing table (NRT) at each
remaining node in the network. This prevents name and number conflicts with future nodes.
Refer to Changing System Names and Numbers for a description of the commands to use to
remove node names and numbers from the NRT.
Changing System Names and Numbers
This subsection explains how to change a system name and number using the
management commands described in the preceding subsections. This explanation is
presented in eight steps. Generally, changing a system name or number is only
necessary if more than one system in the network has the same name or number,
resulting in a conflict.
Caution. If you must change a system name or number, use extreme caution. Changing a
system name or number can adversely affect products and applications that are currently using
the system name or number.
After you change a node number, you might lose access to alternate-key files, such as OSS
configuration files. Refer to the appropriate manuals describing the alternate-key files for
further information. For example, the Open System Services Management and Operations
Guide has a subsection on changing a node number.
Expand Configuration and Management Manual—523347-008
19-22
Managing the Network
Changing System Names and Numbers
Step 1: Save the current configuration file
As a precaution, use the SCF SAVE command to save the current configuration files
on the duplicate nodes. For example, the following command saves the configuration
file at $SYSTEM.ZSYSCONF.CONF0101:
-> SAVE CONFIG 1.1
The SCF SAVE command is described in detail in the SCF Reference Manual for GSeries RVUs.
Step 2: Isolate the duplicate nodes
You must isolate all nodes with the duplicate names or numbers from the network by
stopping all connections between these nodes and those adjacent to them using one
of the following Expand subsystem SCF commands:
ABORT LINE $device_name
ABORT PATH $device_name
Note. Use the ABORT PATH command for multi-line paths. This command affects the
specified line and its associated path logical device; it does not affect other lines in the multiline path.
Step 3: View the current system name and number
View the settings for the system name and number (shown below in bold type) using
the Kernel subsystem SCF INFO SUBSYS command. The following is an example of a
display produced by the SCF INFO SUBSYS command.
3-> info subsys $zzkrn
NONSTOP KERNEL - Info SUBSYS
\TAHITI.$ZZKRN
Current Settings
*DAYLIGHT_SAVING_TIME ................ USA66
*NONRESIDENT_TEMPLATES................ $SYSTEM.SYSTEM.TEMPLATE
*POWERFAIL_DELAY_TIME................. 30
*RESIDENT_TEMPLATES................... $SYSTEM.SYSTEM.RTMPLATE
SUPER_SUPER_IS_UNDENIABLE............ OFF
*SYSTEM_NAME...........................\TAHITI
*SYSTEM_NUMBER.........................82
SYSTEM_PROCESSOR_TYPE ............... NSR-W
*TIME_ZONE_OFFSET..................... -08:00
Pending Changes (will take effect at next system load)
None
The SCF INFO SUBSYS command is described in detail in the SCF Reference Manual
for the Kernel Subsystem.
Expand Configuration and Management Manual—523347-008
19-23
Managing the Network
Changing System Names and Numbers
Step 4: Change the system name and/or system number
You must change the system name and/or system number of one of the duplicate
nodes. To change the system name or number, use the Kernel subsystem SCF ALTER
command. For example:
ALTER, SYSTEM_NAME \EAST
ALTER, SYSTEM_NUMBER 44
If you are changing both the system name and system number, you can more
efficiently use system resources (because these attributes are stored in the server
hardware) by grouping them into one command rather than by entering each
separately; for example:
ALTER, SYSTEM_NAME \EAST, SYSTEM_NUMBER 44
Caution. Be sure that you enter the ALTER command correctly. SCF has no knowledge of a
system name or number that has not been brought up (in an Expand network) since the most
recent load of the local system.
Caution. If the system name and number are to be changed, they should be done at the same
time with a single system load.
The ALTER command is described in detail in the SCF Reference Manual for the
Kernel Subsystem.
Step 5: Confirm the changes
Confirm the changes with another INFO command (changes are shown below in
boldface type). The INFO command displays both the current and the changed values,
which take effect at the next system load.
NONSTOP KERNEL - Info SUBSYS
\TAHITI.$ZZKRN
Current Settings
*DAYLIGHT_SAVING_TIME ................
*NONRESIDENT_TEMPLATES................
*POWERFAIL_DELAY_TIME.................
*RESIDENT_TEMPLATES...................
SUPER_SUPER_IS_UNDENIABLE............
*SYSTEM_NAME..........................
*SYSTEM_NUMBER........................
SYSTEM_PROCESSOR_TYPE ...............
*TIME_ZONE_OFFSET.....................
USA66
$SYSTEM.SYSTEM.TEMPLATE
30
$SYSTEM.SYSTEM.RTMPLATE
OFF
\TAHITI
82
NSR-W
-08:00
Pending Changes (will take effect at next system load)
SYSTEM_NUMBER........................ 44
SYSTEM_NAME.......................... \EAST
Expand Configuration and Management Manual—523347-008
19-24
Managing the Network
Controlling the Network
Step 6: Perform a system load
Because the attributes that change the system name and number are stored in a
SEEPROM in the NonStop S-series server backplane, changes to them will not take
effect until you perform a system load.
Note. You must perform the system load using the Start System button or the Start System
command (under the Operations menu) in either OSM or the TSM Low-Level Link. For more
information, see the online help within each of these applications.
Step 7: Delete the system name and/or system number from
all NRTs
After the system name or system number have been changed and the system loaded,
the following Expand subsystem SCF command should be performed:
DELETE ENTRY $NCP.*
The above command should be performed at every other node in the network to avoid
conflicts in the network routing tables (NRTs) such as duplicate system names or
numbers.
8: Reconnect the nodes to the network
After all nodes in the network have been reset with the SCF DELETE ENTRY $NCP
command, you can safely reconnect the nodes to the network.
Note. The deleted system name and/or system number may appear in the SCF INFO
PROCESS $NCP, LINESET display until the node is reconnected.
Controlling the Network
Network control tasks include the following:
•
•
•
•
Starting and Stopping Expand Line-Handler Processes and $NCP
Stopping and Starting Lines and Paths
Switching Primary and Backup Processes
Rebalancing Multi-CPU Paths
Starting and Stopping Expand Line-Handler Processes and
$NCP
The SCF interface to the WAN subsystem provides commands to control Expand linehandler processes and $NCP. You use the WAN subsystem SCF START DEVICE
command to start and the SCF STOP DEVICE command to stop Expand line-handler
processes and $NCP.
Expand Configuration and Management Manual—523347-008
19-25
Managing the Network
Stopping and Starting Lines and Paths
Stopping and Starting Lines and Paths
The SCF interface to the Expand subsystem provides commands to control lines and
paths. Table 19-11 describes each of these commands and the actions they perform.
Table 19-11. Expand SCF Control Commands
SCF Command
Action Performed
ABORT LINE $device_name
Terminates the operation of a line as quickly as possible.
Only enough processing is done to ensure the security of
the subsystem. The selected line is placed in the
STOPPED state.
ABORT PATH $device_name
Terminates the operation of a path as quickly as possible.
Activity on all lines associated with the path is
terminated. Only enough processing is done to ensure
the security of the subsystem. The selected path and all
associated lines are placed in the STOPPED state.
START LINE $device_name
Initiates the operation of a line. Successful completion
places the line in the STARTED state. The command
affects the specified line and its associated path logical
device; it does not start all lines in a multi-line path.
START PATH $device_name
Initiates the operation of a path. Successful completion
places the path, and all lines associated with the path, in
the STARTED state.
STOP LINE $device_name
Terminates the activity of a line. The command deletes
all connections to and from the line in a nondisruptive
manner. The selected line is placed in the STOPPED
state. The command cannot be used if the line is in the
STARTED state.
STOP PATH $device_name
Terminates the activity of a path and all lines associated
with the path. The command deletes all connections to
and from the path and all associated lines in a
nondisruptive manner. The selected path and associated
lines are placed in the STOPPED state. The command
cannot be used if the path is in the STARTED state.
Switching Primary and Backup Processes
The SCF interface to the Expand subsystem provides commands to change the
primary and backup processes, Table 19-12 describes these commands.
Expand Configuration and Management Manual—523347-008
19-26
Managing the Network
Rebalancing Multi-CPU Paths
Table 19-12. Expand SCF Commands for Switching Processors
SCF Command
Action Performed
PRIMARY PROCESS $device_name
Causes the backup process to become the
primary process, or the primary process to
become the backup process, for a selected
Expand line-handler process.
PRIMARY PROCESS $NCP
Causes the backup process to become the
primary process, or the primary process to the
backup process, for $NCP.
Rebalancing Multi-CPU Paths
The SCF interface to the Expand subsystem provides commands to rebalance multiCPU paths. You can schedule load balancing to occur automatically at periodic
intervals using the SCF ALTER PROCESS $NCP command, or you can manually
initiate load balancing using the SCF ACTIVATE PROCESS $NCP command.
Exactly when you should rebalance a multi-CPU path depends on the volatility of the
traffic pattern. For example:
•
•
•
If the traffic pattern is nearly constant, then load balancing can be initiated once
after a change in the status of the multi-CPU path.
If the pattern changes somewhat during the day, but slowly from day to day, then
load balancing should be done once a day during off-peak hours.
If the pattern changes radically, load balancing should be done an hour or so into
each new traffic pattern to establish new path assignments.
For more information on load balancing, refer to Load Balancing on page 20-16.
Expand Configuration and Management Manual—523347-008
19-27
Managing the Network
Rebalancing Multi-CPU Paths
Expand Configuration and Management Manual—523347-008
19-28
20
Tuning
This section provides guidelines for improving network performance and describes the
tools available for measuring performance. Topics that are explained in this section
include the following:
•
•
•
•
The Role of Network Tuning on page 20-1
Performance Factors on page 20-2
Measuring and Mapping an Expand Network on page 20-22
Tuning Examples on page 20-29
To obtain the greatest benefit from this section, you should be familiar with the material
presented in Section 2, Expand Overview and Section 3, Planning a Network Design.
Note. Adjusting the Expand frame size (FRAMESIZE modifier) in an existing network is not
considered in this section because all nodes in the network must be adjusted simultaneously;
this is impractical for most existing networks. With the multipacket frame and variable packetsize features, the Expand subsystem will send frames larger than the configured frame size.
Therefore, this section discusses network tuning considerations in terms of Expand packet
sizes instead of frame size.
The Role of Network Tuning
Tuning is the tactical adjustment of a network’s dynamic resources to achieve some
well-defined performance goals. Tuning is influenced by—and can influence the
activities of—network planning, configuration, management, and troubleshooting.
Tuning Goals
The following tuning goals are common to the operation of most networks:
•
•
•
Optimizing resource use or minimizing cost
Maximizing the throughput of a certain resource
Minimizing network delay or improving network response time
In this section, resource use refers to processor utilization (the percentage of time the
processor is busy during a given time period); throughput refers to the amount of
traffic that can be handled by an Expand line-handler process; network delay refers to
the time required to process a network request; and network response time refers to
user response time (the time between keyboard lock and keyboard unlock).
While it is not possible to address all three tuning goals simultaneously, you can take
certain actions to improve network efficiency in one or more of these areas. Once
goals have been set, tuning should become a routine operations exercise involving the
balancing of network resources.
Ideally, a network should be designed so that it can be adjusted to accommodate
growth of existing applications, permit additional applications, and take advantage of
new technology. Tuning should not adversely affect fault-tolerant network-design goals.
Expand Configuration and Management Manual—523347-008
20-1
Tuning
Performance Factors
Performance Factors
This subsection describes the factors that can be adjusted to improve Expand linehandler process performance and processor utilization. Performance factors, and their
relative effect on the tuning goals described earlier in this section, are shown in
Table 20-1.
How to Use the Performance Factors Table
To use Table 20-1, vertically scan the Tuning Goals columns. A value of 1 indicates the
greatest effect or impact and is thus the first factor you should examine when
attempting to achieve a specific tuning goal; a value of 6 indicates the least impact. For
example, if you are attempting to optimize resource use, you will look at multipacket
frame size, variable-packet size, and application message size first and Layer 2
window size last.
If more than one performance factor is given the same priority (for example,
multipacket frame size, variable-packet size, and application message size are all
valued at 1), this is an indication that the factors are interrelated and should be
examined simultaneously.
Table 20-1. Performance Factors
Tuning Goals
Performance Factors
Resource Use/Cost
Throughput
Network Delay
Multipacket Frame Size
1
2
3
Variable Packet Size
1
1
3
Application Message Size
1
1
1
Packet Format
5
4
3
Congestion Control
5
1
1
Layer 2 Window Size
6
4
5
Processor Type
(See Note 1)
(See Note 1)
(See Note 1)
NAM Interface
2
2
1
Data Compression
4
3
4
Multi-Line Paths
3
3
3
Multi-CPU Paths
3
3
4
Network Topology
(See Note 2)
(See Note 2)
(See Note 2)
Note 1. Faster processors provide faster response time and higher throughput, given sufficient bandwidth.
Though this factor has a very large impact on the noted goal, it is the most costly or difficult factor to change.
Note 2. Network topology, particularly the location of passthrough nodes, can affect resource use, throughput,
and response time.
The performance goals listed in Table 20-1 are described in detail in the remainder of
this subsection.
Expand Configuration and Management Manual—523347-008
20-2
Tuning
Multipacket Frame Size
Multipacket Frame Size
The multipacket frame feature is designed to reduce processor use at nodes where the
workload is high and the configured frame size must remain unchanged. This feature
enables multiple packets to be placed in a single frame (instead of a single packet in a
single frame). The multipacket frame feature is supported for all line types.
The multipacket frame feature does not change the requirement that all Expand linehandler processes in the network must be configured with the same frame size
(FRAMESIZE modifier). Instead, the multipacket frame feature enables you to increase
the size of frames exchanged on selected paths while still maintaining a single frame
size throughout the network.
Throughput and Frame Size
Note. The following information is not relevant for Expand-over-IP lines. HP recommends that
you configure the variable packet size feature (PATHPACKETBYTES modifier) and extended
packet format (L4EXTENDED_ON modifier) for Expand-over-IP lines. These modifiers
effectively override the packet size calculated from the FRAMESIZE modifier.
The improved throughput achieved by the use of the multipacket frame feature
declines when the frame size (FRAMESIZE modifier) is configured to a value that is
greater than the default of 132 words. The multipacket frame feature cannot be used if
the frame size is greater than 516 words. When the frame size is greater than 516
words, the use of multipacket frames actually lowers throughput below that achieved
when the multipacket frame feature is not selected.
Figure 20-1 shows throughput gains and losses resulting from the use of multipacket
frames.
Expand Configuration and Management Manual—523347-008
20-3
Tuning
Multipacket Frame Size
Figure 20-1. Throughput With and Without Multipacket Frames
Kilobits per second
1800
1600
1400
1200
1000
800
600
400
200
0
132
516
744
Framesize (in words)
Single-packet
Multipacket
VST074.vsd
Processor Use and Message Size
Multipacket frames can improve the processor efficiency of all line types. Directconnect and satellite-connect lines benefit when the average message size is less than
500 words; using multipacket frames for these configurations decreases the number of
interrupts, reducing the number of times the direct-connect or satellite-connect linehandler process is dispatched and causing a reduction in processor use.
There is no improvement in throughput or response time when using multipacket
frames over fixed bandwidth facilities.
Latency and Multi-Line Paths
On multi-line paths, applications that send messages just below the size of the
configured multipacket frame size might experience higher latency since all data is
sent across only one line. Refer to Multi-Line Paths on page 20-13 for more information
about multi-line paths.
Expand Configuration and Management Manual—523347-008
20-4
Tuning
Variable Packet Size
Multipacket Frame Configuration
The multipacket frame size is determined by the value assigned to the
PATHBLOCKBYTES modifier.
When the variable packet-size feature (PATHPACKETBYTES modifier) is used, the
Expand subsystem should be able to send a full variable-size packet inside a
multipacket frame. For this reason, the PATHBLOCKBYTES modifier must be set to a
value greater than or equal to the PATHPACKETBYTES modifier value. Refer to
Variable Packet Size for an explanation of the variable packet-size feature.
When the multipacket frame feature is used, the value specified for the L2TIMEOUT
modifier should be based on the transmission time required for the configured
PATHBLOCKBYTES modifier value rather than on the configured FRAMESIZE
modifier value. You can calculate the value of the L2TIMEOUT modifier using the
following formula:
(((txw + 1) * pathblockbytes * 8 ) / (lspd / 100) + (2 * dl) + 10
where txw is the TXWINDOW modifier value, pathblockbytes is the
PATHBLOCKBYTES modifier value, lspd is the line speed in bits per second (actual,
not configured), and dl is the DELAY modifier value. The result of this formula is a
one-hundredth of a second value.
Note. If you use the Expand subsystem SCF ALTER LINE command to set the L2TIMEOUT
modifier, you must convert the result of this formula to a time interval. For example, if the result
is 300 (3 seconds), you will enter the following command:
ALTER LINE $device_name, L2TIMEOUT 3.00
For more information about configuring the multipacket frame feature, refer to
Multipacket Frame Feature on page 18-64.
Variable Packet Size
The variable packet-size feature is designed to improve bulk transfers across Expand
connections. This feature enables you to configure a maximum packet size for each
path for both single-packet and multipacket frames. This feature effectively overrides
the value configured for the FRAMESIZE modifier between configured nodes. The
variable packet-size feature is supported for all line types.
The variable packet-size feature provides the following benefits:
•
•
•
Reduces per-message processor cost for large message sizes
Reduces network bandwidth used for Expand overhead for large messages
Increases potential throughput in high-bandwidth Expand paths
The variable packet-size feature is especially suited for transferring large messages,
such as in tape backup and restores, and file transfers. While small online transaction
processing (OLTP) requests transfer fastest with smaller frame sizes, larger bulk
Expand Configuration and Management Manual—523347-008
20-5
Tuning
Variable Packet Size
transfers are much more expensive to form into small packets and route in multihop
networks.
Extended Packet Format
The extended packet format (L4EXTPACKETS_ON modifier) provides a means to
fragment packets in transit across the network. The extended packet format must be
enabled for the variable packet-size feature to function.
Although the extended packet format adds considerably more overhead than the
nonextended packet format—the extended packet header size is 64 bytes and the
nonextended packet header size is 16 bytes—the larger packet size more than
compensates for the increased overhead. The variable packet-size feature is designed
to increase the data-per-packet percentage so that only about 10 percent of available
bandwidth is used for non-user data. Refer to Packet Format on page 20-9 for more
information about the extended and nonextended packet formats.
Latency and Multi-Line Paths
On multi-line paths, applications that send messages just below the size of the
configured variable packet size might experience higher latency since all data is sent
across only one line. Refer to Multi-Line Paths on page 20-13 for more information
about multi-line paths.
Expand-Over-IP and Expand-Over-ATM Connections
HP recommends that the variable packet size feature be enabled for Expand-over-IP
and Expand-over-ATM connections. For best performance, the variable packet size
should be set to 4095 bytes for Expand-over-IP and 8192 for Expand-over-ATM
connections.
Variable Packet-Size Configuration
The variable packet size is determined by the value assigned to the
PATHPACKETBYTES modifier. Since the Expand subsystem sends larger frames than
those configured by the FRAMESIZE modifier when the variable packet-size feature is
enabled, the value specified for the L2TIMEOUT modifier should be compatible with
the largest possible packet rather than the frame size. You can calculate the value of
the L2TIMEOUT modifier using the following formula:
(((txw + 1) * pathpacketbytes * 8) / (lspd / 100)) + (2 * dl) + 10
where txw is the TXWINDOW modifier value, pathpacketbytes is the
PATHPACKETBYTES modifier value, lspd is the line speed in bits per second (actual,
not configured), and dl is the DELAY modifier value. The result of this formula is a
one-hundredth of a second value.
Expand Configuration and Management Manual—523347-008
20-6
Tuning
Application Message Size
Note. If you use the Expand subsystem SCF ALTER LINE command to set the L2TIMEOUT
modifier, you must convert the result of this formula to a time interval. For example, if the result
is 300 (3 seconds), you will enter the following command:
ALTER LINE $device_name, L2TIMEOUT 3.00
For more information about configuring the variable packet-size feature, refer to
Variable Packet Size Feature on page 18-68.
Application Message Size
Application message size is the number of data bytes sent to an Expand line-handler
process by a higher-level process. The application message size has a major effect on
Expand line-handler process processor overhead and Expand subsystem overhead,
which can affect throughput. By increasing the application message size, you can
greatly increase potential throughput and decrease processor use.
Application Message Size and Data Flow
Figure 20-2 shows the flow of data from an application on one node to an application
on another node through an Expand-over-IP line-handler process. Application A, in its
request to the message system, defines the application message size.
Figure 20-2. Application Data Flow for Expand-Over-IP
System \A
System \B
Application
A
Application
B
Via
Message
System
Via
Message
System
Expand
Expand
Via
Message
System
Via
Message
System
TCP/IP
Process
TCP/IP
Process
Ethernet LAN
VST073.vsd
Expand Configuration and Management Manual—523347-008
20-7
Tuning
Application Message Size
As shown in Figure 20-2, the message system recognizes that the data is to be sent to
an application that is not on the local node, and it routes the request to the appropriate
Expand line-handler process.
If the Expand packet size is large enough to hold all of the message from the
application, the Expand line-handler process puts the message into a single packet. If
the Expand packet size is smaller than the message that the application wants to send,
the Expand line-handler process must send more packets across the message system
to the NonStop TCP/IP process.
Expand Subsystem Overhead
It is important to consider Expand subsystem overhead when using facilities with
limited bandwidth. Application message size and Expand packet size have significant
effects on subsystem overhead. The number of Expand packets required for an
application message is calculated using the following formula:
1 + $INT((app_msg + fsm) / (packet_size - pkt))
app_msg
is the user message size in bytes.
fsm
represents the file system and Expand message header information (in bytes) sent
at the start of each message.
packet_size
is the maximum number of bytes per packet. If the variable packet size feature is
used, packet_size is the PATHPACKETBYTES modifier value; otherwise,
packet_size is equal to (frame_size - 4 )* 2 where frame_size is the
FRAMESIZE modifier value. The default is 256.
pkt
represents the Expand Layer 2 and packet header information (in words) sent at
the start of every Expand frame.
Expand Configuration and Management Manual—523347-008
20-8
Tuning
Packet Format
The values of fsm and pkt vary according to the oldest version of the Expand
subsystem at the originating and destination nodes, as shown in Table 20-2.
Table 20-2. Message Header and Packet Header Overhead
Expand Version
fsm (Bytes)
pkt (Bytes)
C30.08 and earlier
53
16
C30.09
49
64
D10
89
16
D20 and later
95
64
For example, if an application message of 500 bytes is sent from a G02 version of the
Expand subsystem to another G02 Expand node, the number of Expand packets
required is calculated as follows:
1 + $INT((500 + 95) / (256 - 64)) =
1 + $INT (595 / 192) =
1 + $INT (3.09) = 4
Packet Format
The Expand subsystem enforces a minimum value of 1024 bytes for the variablepacket size (set with the PATHPACKETBYTES modifier). The default value for
PATHPACKETBYTES (1024 bytes) yields the same data-per-packet percentage as
nonextended packets with a frame size of 132 words.
Table 20-3 compares the data-per-packet percentages for nonextended packet
(L4EXTPACKETS_OFF modifier) and extended packet (L4EXTPACKETS_ON
modifier) header formats. An Expand network using a frame size of 132 words is
assumed.
Table 20-3. Data-Per-Packet Percentages
Packet
Header
Format
PATHPACKETBYTES
Modifier Value (Bytes)
Packet
Size
(Bytes)
Packet
Header
(Bytes)
Data
Portion
(Bytes)
Percentag
e
(Bytes)
Nonextended
Any
256
16
240
93.75
Extended
0
256
64
192
75.00
Extended
1024
1024
64
960
93.75
Extended
4095
4095
64
4031
98.44
Note. The variable packet-size feature cannot be used with the L4EXTPACKETS_OFF
modifier.
Expand Configuration and Management Manual—523347-008
20-9
Tuning
Congestion Control
Although the data-per-packet percentage is highest when the PATHPACKETBYTES
modifier is set to 4095 bytes, there are other effects of using a 4095-byte packet size
that you must consider. One of these considerations is the effect of the packet size on
a multi-line path. Refer to Multi-Line Paths on page 20-13 for more information about
packet size and multi-line paths.
Congestion Control
The Expand subsystem’s congestion control feature improves throughput in networks
that are subject to varying delays. The congestion control feature allows a connection
to reach an equilibrium point slowly and then pick up speed as additional bandwidth is
found. An additional mechanism allows quick error-recovery without wasting bandwidth
and is more efficient than the out-of-sequence timer recovery provided by Expand linehandler processes that do not use the congestion control feature.
In networks with low delay variance and few or no errors, the congestion control
feature provides up to 8 percent improvement in response time with no significant
difference in processor utilization. In networks with high delay variance, the benefits of
congestion control are more significant, as recovery from lost packets due to
congestion is handled much more efficiently. In networks with high error or packet-loss
rates, congestion control provides a more efficient error-recovery mechanism;
however, congestion control cannot solve problems caused by noisy lines or poorly
configured bridges and routers.
Expand-Over-IP Connections
Expand-over-IP line-handler processes use the User Datagram Protocol (UDP)
services provided by a NonStop TCP/IP process to transmit data across an Internet
Protocol (IP) network. Because data transfer with UDP is not guaranteed, the Expand
End-to-End protocol is used to achieve reliable communications for Expand-over-IP
connections. You can avoid congestion and improve error-recovery by enabling the
congestion control feature on Expand-over-IP connections.
Congestion Control Configuration
You can enable the congestion control feature for outgoing transmissions on a perconnection basis using the L4CONGCTRL_ON modifier. HP recommends that you
enable the congestion control feature for all connections in your Expand network.
If your network contains some Expand line-handler processes that support the
congestion control feature and some that do not, HP recommends that you enable the
feature for all connections that are capable of congestion control and set the out-ofsequence (OOS) timeout value (OSTIMEOUT modifier) to the default value of 3
seconds for all Expand line-handler processes.
If all nodes in the network are running D30 or later versions of the Expand subsystem,
then HP recommends that the congestion control feature be enabled for all Expand
line-handler processes and that the OOS timeout value be set to 10 seconds.
Expand Configuration and Management Manual—523347-008
20-10
Tuning
Layer 2 Window Size
For more information about configuring the congestion control feature, refer to
Congestion Control Feature on page 18-71.
Layer 2 Window Size
At the OSI Data Link Layer (Layer 2), the mechanisms for flow control and windowing
are provided by the particular Layer 2 protocol used (for example, HDLC or, if a
network access method (NAM) is used, SNAX/APN, X25AM, ServerNet, or FOX).
Small Layer 2 windows (as specified with the TXWINDOW modifier) tend to use
communications lines inefficiently. Large Layer 2 windows can be used effectively
when propagation delay is long or line quality is very high.
Note. A small Layer 2 window size can be used to cope with poor quality lines when line
efficiency is not important.
For Expand-over-IP connections, the TXWINDOW modifier specifies the number of
packets the Expand-over-IP line-handler process can send to the NonStop TCP/IP
process (with which it is associated) before waiting for a reply from the NonStop
TCP/IP process; it does not control the transfer of data across the link.
Processor Type
The processing power of the NonStop S-series servers (through which a message is
transmitted) determines throughput if there are no bottlenecks in the other components
of the network. The relative processor power factors are a good starting point for
estimating Expand line-handler process performance limits.
Process location and load balancing within a system can also have a major impact on
network performance. The same type of analysis used for any other NonStop™
process can also be applied to Expand line-handler processes.
NAM Process Configuration
Configuring an Expand-over-NAM line-handler process and a NAM process in the
same processor is more processor-efficient than configuring these processes in
separate processors.
However, when an Expand line-handler process and the NAM process it uses are in
the same processor, total throughput is limited. Because you can configure an Expand
line-handler process and its associated NAM process in separate processors, you can
achieve a combined processor usage of greater than 100 percent for this type of
Expand connection.
Note. In general, the newer processor types are faster than the older processor types. Contact
your HP representative for detailed performance information regarding a specific type of HP
processor.
Expand Configuration and Management Manual—523347-008
20-11
Tuning
NAM Interface
For more information about Expand-over-NAM line-handler process configuration, refer
to Section 10, Configuring Expand-Over-X.25 Lines and Section 14, Configuring MultiLine Paths.
Expand-Over-IP Configuration
Expand-over-IP line-handler processes use a NonStop TCP/IP process to provide
TCP/IP connectivity. The NonStop TCP/IP process associated with the Expand-over-IP
line-handler process must be configured in the same processor pair as the Expandover-IP line-handler process.
With Parallel Library TCP/IP and NonStop TCP/IPv6, the Expand line-handler process
must be configured in a processor where a TCPMON or TCP6MON process is running;
this usually yields a free choice of processor. It is not necessary nor beneficial in any
way to co-locate the Expand line-handler process and the TCPSAM or TCP6SAM
process.
For more information about Expand-over-IP line-handler process configuration, refer to
Section 8, Configuring Expand-Over-IP Lines.
NAM Interface
When a NAM interface is used, Layer 2 functions are managed by the NAM process,
thus reducing the load on the Expand line-handler process. Although the Expand linehandler process has a potentially greater upper throughput limit when it uses a NAM
interface, overall system processor requirements are not reduced because some of the
workload is shifted to the NAM process. There is also an additional cost per packet for
the interprocess message between the Expand line-handler process and the NAM
process.
On a high-powered processor, such as a NonStop S-series server, this extra available
processor power can allow an Expand line-handler process to drive multiple highspeed lines and greatly extend throughput.
The relationship between the size of the Expand packet and the NAM network native
packet size has a major influence on the available Expand line-handler process
bandwidth. Each Expand packet passed to the NAM is treated as a message by the
NAM.
If the NAM network native packet size is smaller than the Expand packet size, the NAM
process must fragment the Expand packet. If the Expand packet size is smaller than
the NAM packet size, the number of messages to the NAM will be higher than if the
Expand packet size were the same size as the NAM packet size.
Expand Configuration and Management Manual—523347-008
20-12
Tuning
Data Compression
Data Compression
Data compression indirectly affects Expand line-handler process performance. By
shortening the length of a message, compression can reduce the number of packets
transmitted.
Because the data compression feature has an insignificant impact on the processor,
data compression should always be enabled unless you are certain that no data is
compressible. If compression is enabled and data is not compressible, data
compression actually causes messages to be slightly longer because the Expand
subsystem inserts a compression word every 255 words (510 bytes) of the message.
You can increase network efficiency by analyzing routine data to determine the degree
of compressibility and then setting the frame size to carry the largest data-compressed
message. This technique can be a very effective way to economize processor
resources for point-to-point links with heavy, large-block message traffic.
Data compression is configured using the COMPRESS_ON modifier.
Multi-Line Paths
The multi-line path feature enables you to configure eight parallel lines between the
same two nodes. The advantages of multi-line paths include increased fault-tolerance
and additional bandwidth.
The main disadvantage of multi-line paths is increased processor overhead, which
occurs primarily because extra processing must be done to select the best line for
each frame transmitted and to guarantee sequencing of packets received across
multiple lines. However, the reduction in queuing delays that results from using a multiline path usually offsets the extra processor delay.
The interaction of some elements of the Expand network determine the degree of
improvement multiple lines might achieve. These are the elements that control the
service rate of the Expand line-handler processes (including the NAM process, if
used), and the use of the lines in the path. These elements include the following:
•
•
•
•
Processor type
Packets per message
Window size
Variable packet size
Note. Line message rate can also affect the degree of improvement achieved by multiple
lines. For example, if the line message rate is low, multiple lines will not significantly improve
performance. An application, rather than a line, might sometimes be the cause of a bottleneck.
Expand Configuration and Management Manual—523347-008
20-13
Tuning
Multi-Line Paths
Processor Type
The processor overhead for serving multiple lines is greater than the processor
overhead for serving one line per path for an equivalent volume of throughput. The
degree of increased cost depends on the processor type, the version of the Expand
software used, and the speed differences (if any) between the lines.
Packets Per Message
While a large message fragmented into small packets might make more efficient use of
the communications bandwidth than a message in a single large packet, it takes more
processor time for the fragmentation and the reassembly.
A single high-speed line might be a better solution than multiple lines, especially from
the standpoint of processor efficiency, when a single important application dominates
the performance considerations. If the variable packet-size feature is used with multiple
lines, the PATHPACKETBYTES modifier value should be configured to use all lines in
the multi-line path equally.
Refer to Variable Packet-Size Configuration on page 20-6 for more information about
the variable packet-size feature.
Window Size
If a line is added to a path using a different protocol or telecommunications network at
Layer 1, the path might have different delay characteristics from the original single line.
It might be necessary to change the Layer 2 window size (TXWINDOW modifier) to
minimize any delays introduced by switches or new protocols.
In some situations, the HDLC Extended protocol might be advantageous on terrestrial
links. Some terrestrial networks, especially those that include private switches and
CBXs, can have variable delays that at times are as great as a 0.25-second satellite
hop. If queuing for an Expand line-handler process occurs in such a network, yet the
process and communications use is low, switching delay might be the cause and using
the HDLC Extended protocol might be advisable.
Variable Packet Size
Variable packet size effectively increases the Expand packet size to 1024 bytes or
greater. Multi-line paths can distribute data across available lines more evenly when
the packet size is smallest. Applications that send messages just below the size of the
configured variable packet size over multi-line paths might notice an increase in
latency since all data is sent across only one line.
For example, a four-line path with a variable packet size (PATHPACKETBYTES
modifier) of 4095 bytes will only use the first line for all requests of 4 Kbytes or less
unless multiple requests are received simultaneously. If the PATHPACKETBYTES
modifier is configured at the default (1024 bytes), requests larger than 4 Kbytes will
utilize all four lines more evenly.
Expand Configuration and Management Manual—523347-008
20-14
Tuning
Multi-CPU Paths
The general formula for configuring the variable packet size for multi-line paths using
low to medium bandwidth lines is as follows:
PATHPACKETBYTES = average_message_size / number_of_lines
If the average message size is not known, you can use the Expand subsystem SCF
command PATH STATS to display a histogram of message sizes.
Multi-CPU Paths
The multi-CPU path is the fundamental component of the Expand multi-CPU feature. A
multi-CPU path can consist of up to 16 individual Expand paths, including multi-line
paths. Expand-over-ServerNet and Expand-over-FOX line-handler processes cannot
participate as members of a Superpath.
The main advantages of the Expand multi-CPU feature include the following:
•
•
•
Higher total throughput
More even spreading of the communications load over multiple processors
Reduced message system interprocessor traffic
The main disadvantage of the Expand multi-CPU feature is that its advantages are
available only when traffic fits a certain pattern. For example, if most traffic occurs
between the same two nodes—or if these nodes are direct neighbors and traffic is sent
between the same two processors in one direction—then the Expand multi-CPU
feature cannot spread the load effectively. Other disadvantages include the following:
•
•
Increased processor overhead
The possibility of occasional disruptions during load balancing
The interaction of some elements of the system and of the Expand network determine
the degree of performance improvement that the Expand multi-CPU feature might
achieve. These are the elements that control how well the Expand multi-CPU feature
can spread traffic over its constituent paths.
These elements include the following:
•
•
Traffic Pattern
Load Balancing
Traffic Pattern
Unlike a multi-line path, which can spread traffic evenly over all of its lines regardless
of the traffic pattern, a single path within a multi-CPU path is assigned to traffic
between each pair of endpoints. This path assignment is fixed until traffic is rebalanced
over all the paths in the multi-CPU path. For this reason, the more that traffic is spread
across different endpoints, the better a multi-CPU path can spread the load across its
member paths.
Expand Configuration and Management Manual—523347-008
20-15
Tuning
Multi-CPU Paths
Note. Endpoints are considered to be different if they are on different nodes or, if the remote
node is a neighbor node, on different local and remote processors and different directions.
For example, if nearly all traffic in an Expand network is sent between the same two
processes in one direction, then the multi-CPU path can only assign this traffic to one
path and the other paths will remain virtually idle.
In another scenario, the traffic pattern might not be optimal at first, but a change in
configuration could improve it; often this configuration change will benefit overall
performance as well as multi-CPU path performance. For example, if nearly all traffic is
between the same two non-neighbor nodes but on different processors on each node,
the multi-CPU path can only assign the traffic to one path. However, if new paths are
configured directly between these nodes, making them neighbors, then the multi-CPU
path can spread the traffic over multiple paths.
You should be aware of the traffic pattern in your network before configuring multi-CPU
paths.
Load Balancing
When a multi-CPU path initially assigns paths to each pair of endpoints, the traffic
pattern is usually not yet known. Load balancing is used to correct this problem as
more information is gathered by moving Expand line-handler process pairs from more
heavily loaded paths to more lightly loaded paths within the multi-CPU path. A slight
disruption occurs in message transfer occurs when pairs are changed. This disruption
is similar to what can occur when a better route is found in the Expand network and
connections are reestablished over the new best-path route.
You can schedule load balancing to occur automatically at periodic intervals or you can
initiate it manually. Exactly when you should rebalance a multi-CPU path depends on
the volatility of the traffic pattern. For example:
•
•
•
If the pattern is nearly constant, then load balancing can be initiated once after a
change in the status of the multi-CPU path.
If the pattern changes somewhat during the day, but slowly from day to day, then
load balancing should be done once a day during off-peak hours.
If the pattern changes radically, load balancing should be done an hour or so into
each new traffic pattern to establish new path assignments.
A maximum of 16 moves can be put on the output change list. All of the above stop
when that count is reached. Pairs on the change list are flagged with an anti-thrashing
bit; selection of those pairs for moving is avoided during the next one rebalance.
Because rebalancing is slightly disruptive, $NCP changes Expand line-handler process
pairs only at the following times:
•
When a new path comes up. (This is similar to what happens in normal paths when
a new path that has a lower TF is discovered.)
Expand Configuration and Management Manual—523347-008
20-16
Tuning
•
•
•
Multi-CPU Paths
At configurable times during the day. You can use the SCF ALTER PROCESS,
AUTOREBALANCE command to specify when rebalancing should occur. Both the
time of day and the interval between rebalance attempts can be specified, allowing
you to schedule a rebalance when traffic is minimal.
Immediately. You can use the SCF RESET PROCESS command to cause an
immediate rebalance.
When a path goes down. (In this case, the rebalancing algorithm is not actually
used; instead, new connections are set up according to the current load.)
Superpath Load Distribution
The Superpaths feature does not distribute the load equally over all paths. A superpath
distributes the load based on three criteria:
•
•
•
CPU Matching
Load Factor Balancing
Pair Count Balancing
CPU Matching
This takes effect when the two systems are directly connected with a superpath; that
is, they are direct neighbors. The system matches up the local and remote CPUs of the
two processes sending and receiving the messages with a line handler on the same
CPUs.
Figure 20-3 illustrates two systems that have a superpath connecting them, with a line
handler on CPU 1 and CPU 3:
Figure 20-3. CPU Matching
\A
\B
CPU 0
CPU 0
CPU 1
CPU 1
CPU 2
CPU 2
CPU 3
CPU 3
VST008.vsd
Expand Configuration and Management Manual—523347-008
20-17
Tuning
Multi-CPU Paths
A process on \A in CPU 1 that is communicating with a process on \B in CPU 1 will use
the line handler configured on CPU 1. If another process on \A in CPU 1 is started that
also communicates with a process on \B in CPU 1, the same line handler would be
used (the one on CPU 1). This is because of the CPU matching rules.
If no line handler directly connects the two CPUs, a best match is done. A process on
\A in CPU 0 that is communicating with a process on \B in CPU 3 will use the line
handler configured on CPU 3. That is the line handler that has the best match—the
remote Rhinelander CPU matches the destination process CPU.
Load Factor Balancing
If there are no matching CPUs, then the load would be distributed based on the load
factor of the paths in the superpath.
If a process on \A in CPU 0 is communicating with a process on \B in CPU 2, the line
handler chosen is based on the load factor of the two lines.
Once the CPU pair has been established, that line handler is used for all
communication between the two CPUs. In an example of CPU 0 to CPU 2 and
assuming that the line handler in CPU 3 is the one chosen, all traffic from CPU 0 to
CPU 2 uses the line handler in CPU 3.
Note. The selection algorithm is such that the more loaded line can still be chosen. When a
new connection is being established, the selection algorithm not only looks at the load factor,
but also checks to see if this path has been chosen recently. A loaded path can still be chosen
as the one for a new connection. This way, a single line that looks unused at the time won't get
all of the new connections assigned to it, but they will be distributed over the superpath.
Pair Count Balancing
If the loads are fairly close, the number of CPU pairs using the paths in a superpath is
looked at in determining the connection.
Figure 20-4 depicts the loading for systems that are direct neighbors and are
connected with a superpath, plus connections for non-neighbors:
Expand Configuration and Management Manual—523347-008
20-18
Tuning
Multi-CPU Paths
Figure 20-4. Pair Count Balancing for Neighbors and Non-Neighbors
\A
\B
CPU 0
CPU 0
CPU 1
CPU 1
CPU 2
CPU 2
CPU 3
CPU 3
\C
\D
VST009.vsd
\A and \B are connected with a superpath, \C is connected to \B, and \D connects to
\C.
In reference to \A, \B is a neighbor and \C and \D are non-neighbors. When \A makes a
connection to \C, the load is not distributed over different paths, but only one path is
used for all traffic to \C.
In order to make sure that the correct path is used, \B records which line handler is
used for \A's connection to \C. This is done by setting an entry in the reverse pairing
table so \B knows which line handler to send the packets from \C to \A.
The reverse pairing table on \B can be displayed with the SCF command:
-> INFO PROCESS $NCP, RPT \A
This displays which line handlers \B and \A are using for the connections which \A has
that go through \B.
When \A makes a connection to \D, a different line handler might be selected as the
one to carry the traffic from \A to \D. This way, the load to different non-neighbors can
be distributed among the different paths in the superpath. However, the traffic to a
single non-neighbor only uses one of the paths in the superpath.
Expand Configuration and Management Manual—523347-008
20-19
Tuning
Multi-CPU Paths
Superpath Rebalancing
Superpath rebalancing is run periodically to correct path selection as traffic patterns
change. It has three goals:
•
•
•
CPU Matching: Make sure all source/destination pairs are using a path with the
most CPU matches available (same local/remote CPU).
Load Factor Balancing: Try to make the load factors (LF = ETF / TF) of all paths
within 0.5 of each other.
Pair Count Balancing: Spread those pairs whose traffic have no adverse impact on
load factors (LFs) over all paths in inverse proportion to their effective time factors
(ETFs).
The three goals are handled in three separate steps.
1. First, CPU matching is done for each source/destination pair by looking for line
handlers that have better CPU matches than their current owner. If more than one
path has the best match, choose the one that yields the lowest predicted loadfactor spread. The pair is moved without regard for anti-thrashing bits (see below)
or possible increase in the load-factor spread.
2. Next, the load factors are balanced. The load-factor spread is the highest load
factor minus the lowest load factor; this step tries to minimize the load factor
spread until it is less than 0.5. To do this, calculate the sensitivity of each path's
load factor to its total traffic, assuming a linear relationship between average ETF
and total traffic. This is used to predict the effect on the load factors of moving
traffic from one line handler to another.
Then consider moving each pair from each other line handler to the one with the
lowest load factor, and of moving each pair from the line handler with the highest
load factor to each other line handler and predict the resulting change in load
factors.
Choose the single move that results in the lowest predicted load factor spread, put
it on the output change list, update the load factors according to the predicted
changes, and check the new load factor spread value. This is continued until the
load factor spread is less than 0.5 or no moves can be found that improve the load
factor spread.
3. Lastly, the pair counts are balanced. Use the path selection algorithm described
above with current ETF information to determine the goal number of pairs for each
line handler. To prevent new line handlers with low ETFs and no current pairs from
taking on more pairs than they can actually handle, those line handlers with too few
pairs have their goals reduced by half their shortfall.
Then consider moving each pair from the line handler with the highest excess pairs
to each line handler with a dearth. Choose the move that results in the lowest
predicted load-factor spread with no increase from previous efforts. If more than
one path has the same lowest load-factor spread, choose the one with the largest
Expand Configuration and Management Manual—523347-008
20-20
Tuning
Network Topology
pair-count shortfall. This is continued until there are no excess pairs or all possible
moves increase the load-factor spread.
Network Topology
Network topology is the pattern of interconnection of nodes in the network. Network
topology, particularly the location of passthrough nodes, can affect response time.
Passthrough traffic is shown in Figure 20-5.
Figure 20-5. Passthrough Traffic
Node \A
Node \C
Node \B
$LINEB
$LINEA
$LINEC
$LINEB
VST049.vsd
As shown in Figure 20-5, node \B handles passthrough traffic between node \A and
node \C, so it must have two Expand line-handler processes: one for node \A and one
for node \C. As a result, passthrough traffic uses at least twice as much processor time
as does direct traffic.
Note. The advantages and disadvantages of different network topologies are discussed in
Section 3, Planning a Network Design.
Passthrough data has a 4-to-1 priority over locally originated data. This ratio is tuned
fairly well for small passthrough packets. If all nodes in a route are configured for a
large variable packet size (PATHPACKETBYTES modifier) such as 4095 bytes, the
intermediate nodes can send up to 16 Kbytes of passthrough traffic between packets of
a locally originated message.
Configuring a large variable packet size might have undesirable consequences at
nodes in Expand networks that support network applications and provide connectivity
between other network nodes. Using the default value for PATHPACKETBYTES (1024
bytes) allows a maximum of 4 Kbytes of passthrough data between locally originated
packets; however, each local request can now be up to 1 Kbytes.
Expand Configuration and Management Manual—523347-008
20-21
Tuning
Summary of Tuning Strategies
Summary of Tuning Strategies
Table 20-4 summarizes the strategies that you can use to achieve your tuning goals.
Table 20-4. Summary of Tuning Strategies
Goal
Strategies
To optimize resource use
and minimize cost
Use the multipacket frame feature for OLTP applications and
the variable packet size feature for bulk data transfers. Both
features can be used on the same path.
Minimize passthrough traffic to save time and capital costs
while maintaining fault-tolerance.
Use single-line paths where possible.
To maximize throughput
Use the multipacket frame feature for OLTP applications and
the variable packet size feature for bulk data transfers. Both
features can be used on the same path.
Provide adequate communications bandwidth to meet the path
demand.
Configure Expand line-handler processes to use data
compression (COMPRESS_ON modifier).
Install single high-speed lines rather than multiple low-speed
lines.
To minimize delay
Use direct connections between nodes to avoid passthrough
and its associated delays.
Do not use X.25 or store-and-forward type switches.
Use two or more times the communications line capacity than
is required to minimize queuing delays.
Configure Expand line-handler processes in lightly loaded
processors.
Configure Expand-over-NAM line-handler processes in the
same processor if that processor has sufficient capacity.
Avoid satellite connections in multiple hop topologies. (Use
satellite connections where the network has delays.)
Measuring and Mapping an Expand Network
Effective network tuning must begin with an accurate picture of the network and its
significant traffic. All networks are fully defined topologically by their nodes and links.
Network traffic is fully defined by the intensity of the traffic, the service times of the
working components, and the capacities of passive resources such as buffers and
queues. These parameters can all be measured by HP utilities.
Because it is not always feasible to define every network fully, your first task is to
create a working definition of a subnetwork adequate to serve tuning goals. HP
provides several tools for building this model:
Expand Configuration and Management Manual—523347-008
20-22
Tuning
•
•
•
•
•
What the Utilities Show
Subsystem Control Facility (SCF). Provides a good view of long-term network
behavior. The SCF interface to the Expand subsystem is described in Section 15,
Subsystem Control Facility (SCF) Commands.
Measure. Can be used to make a detailed study of a particular node’s Expand linehandler processes and paths and short-term network traffic intensity. Measure is
described in the Measure User’s Guide.
Enform. Can be used for data reduction that can be analyzed by proprietary tools
on the NonStop S-series server or can be used with analytical or simulation tools
elsewhere. The Enform optimizer can be used to produce charts such as those
shown later in this section. ENFORM is described in the Enform Reference Manual
and Enform User’s Guide.
Availability Statistics and Performance (ASAP)
The Availability Statistics and Performance (ASAP) monitoring tool provides
graphical and tabular displays of system and network object performance, object
state, and entity threshold information. The Availability Statistics and Performance
Extension (ASAPX) product integrates and extends ASAP monitoring capabilities
to single and multi-node application environments. For more information about
ASAP, refer to the following manuals: ASAP Client Manual, ASAP Server Manual,
ASAP Extension Manual, and ASAP Migration Guide for NSX and OMF Users.
What the Utilities Show
Virtually all the information needed to model and tune an Expand network can be
gathered by SCF and Measure.
SCF is specifically designed to monitor network components. SCF is adequate to map
the topology of any Expand network, but it is not designed to define the traffic
completely.
Measure is a general-purpose measuring tool that reports details on the performance
of several Expand components.
Using Measure
The Expand components reported on by Measure are called entities. Once you have
mapped your network and selected the nodes you want to measure, you can
characterize the network traffic by measuring the following entities:
•
•
•
•
•
SYSTEM Entity
NETLINE Entity
LINE Entity
PROCESS Entity
CPU Entity
Note. The values shown in the following diagrams are in units per second (the Measure SET
REPORT RATE ON command was used).
Expand Configuration and Management Manual—523347-008
20-23
Tuning
Using Measure
SYSTEM Entity
The SYSTEM entity provides information about traffic that originates or terminates at
the measured system. This traffic is measured in the form of messages and is reported
as a count of links.
The SYSTEM entity also shows the number of Expand frames sent and received.
Passthrough Expand frames are counted as Sent-Forward or Received-Forward
frames. Sent-Forward frames did not originate at the local node; Received-Forward
frames are not destined for the local node.
Note. Passthrough traffic might also be referred to as forwarded or switched traffic.
Example 20-1 is an example of a SYSTEM entity display.
Example 20-1. SYSTEM Entity Display
Remote System \SSG
System Number 73
Local System \PEEWEE From 9 Jan 1997, 13:13:11 For 7.5 Minutes
Links
38.24
Link-Time
0.22
Sent
76.53
Received
38.44
Sent-Forward
0.02
Received-Forward 0.12
NETLINE Entity
The NETLINE entity reports several values that you need when modeling traffic on a
path. NETLINE reports part of the path performance associated with a particular
Expand line-handler process, logical device, and ServerNet wide area network (SWAN)
concentrator.
The number of data bytes received is shown in Din4-Bytes and the number of bytes
sent is shown in Dout4-Bytes.
NETLINE also shows the distribution of message sizes in message-size ranges. This
information corresponds to the histogram shown by the SCF interface to the Expand
subsystem. However, unlike SCF, Measure shows only the histogram for the measured
interval.
Example 20-2 shows traffic intensity during a 34.7 second period beginning at
11:53:37. During this period, 1.27 messages of 605.14 bytes were sent per second.
(Relevant information is highlighted in boldface type.)
Expand Configuration and Management Manual—523347-008
20-24
Tuning
Using Measure
Example 20-2. NETLINE Entity Display
Network Line $B30S
Device Type 63
Subdevice Type 5
Logical Device 178 TRACKID SWAN38
Clip 3
Line 0
Local System \TAHITI From
7 Feb 1997, 11:53:37
For 34.7 Seconds
Requests
Write-Busy-Time
Read-Busy-Time
L2in-Bytes
Din4-Bytes
Cin4-Bytes
U64-Bytes
U256-Bytes
U1024-Bytes
U4096-Bytes
1.27
2.21 %
98.07 %
1,204
773.09
411.55
4.82
0.61
0.03
0.12
Writes
Reads
L2out-Bytes
Dout4-Bytes
Cout4-Bytes
U128-Bytes
U512-Bytes
U2048-Bytes
O4095-Bytes
11.97
9.34
1,589
605.14
359.61
2.05
0.23
NETLINE Din4-Bytes and Dout4-Bytes counters include file-system and messagesystem overhead and are measured before data compression. L2in-Bytes and L2outBytes counters represent traffic between the input-output process (IOP) and the driver.
The application Link Complete (LCMP) is included in the U64-Bytes category of the
NETLINE display. Application LCMPs are also shown in the Links Received counter for
the SYSTEM entity. The other NETLINE categories report message frames only.
LINE Entity
The LINE entity accounts for the traffic sent by the Expand line-handler process or the
NAM process to and from the OSI Physical Layer (Layer 1). In the sample display
shown in Example 20-3, the NAM process $X25TAH sent about 1,344 data bytes with
204 bytes of overhead. The Output-Data-Bytes counter and the Input-Data-Bytes
counter show the bytes sent and received by the NAM process or Expand line-handler
process. The Output-Bytes counter shows the data plus the Layer 2 overhead.
(Relevant information is highlighted in boldface type.)
Example 20-3. LINE Entity Display
Comm Line $X25TAH
Device Type 61
Subdevice Type 63
Logical Device 170 Trackid SWAN24
Clip 2
Line 1
Local System \COWBOY From
7 Feb 1997, 10:23:51
For 44.3 Seconds
Requests
Write-busy-Time
Read-busy-Time
Input-Bytes
Input-Data-Bytes
Transactions
6.03
1.21 %
85.52 %
946.94
770.93
Retries
Writes
Reads
Output-Bytes
Output-Data-Bytes
Response-Time
Expand Configuration and Management Manual—523347-008
20-25
11.97
12.08
1,548
1,344
Tuning
Using Measure
PROCESS Entity
The PROCESS entity reports processor use and data sent and received by the Expand
line-handler process. It also reports the messages sent and received between the
Expand line-handler process and the applications it is serving. Although the data
counts do not include all of the overhead of the lower layers, they do include the
NonStop™ Kernel and Expand headers and any compression words.
Note. The Cpu-Busy-Time counter does not include all the processor resources used by the
Expand line-handler process. To more precisely determine processor use of an Expand linehandler process, you must use values provided by both the PROCESS and CPU entity
displays. Using the PROCESS and CPU entity displays to determine processor use is
explained in Determining Processor Use on page 20-27.
Example 20-4 shows that $B30S received 33 Kbytes per second and sent
approximately 35 Kbytes after adding framing bytes. $B30S was busy 31.20 percent of
the measured time and was dispatched 48.13 times per second. Messages-Sent and
Messages-Received show the number of frames sent and acknowledgments received
from the NAM process per second. (Relevant information is highlighted in boldface
type.)
Example 20-4. PROCESS Entity Display
Process 3,14
($B30S)
Pri 199
Pg Size
16384 Bytes
Program $SYSTEM.SYS01.LHOBJ (Native)
Userid
255,255
Creatorid 255,255
Ancestor 1,275 ($ZZWAN)
Local System \TAHITI From
7 Feb 1997, 11:53:36
For
3.3 Minutes
Cpu-Busy-Time
Mem-Qtime
Page-Faults
Pres-Pages-Qtime
Ext-Segs-Qtime
Recv-Qtime
Messages-Sent
Sent-Bytes
Returned-Bytes
MQC-Allocations
MQCs-Inuse-Qtime
Checkpoints
File-Open-Calls
UCL-Qtime
Accel-Busy-Time
TNSR-Busy-Time
Begin-Trans
31.20 %
315 #
2 #
0.12
138.36
35,171
Ready-Time
Dispatches
Vsems
Pres-Pages-Max
Ext-Segs-Max
Recv-Qlen-Max
Messages-Received
Received-Bytes
Reply-Bytes
MQC-Alloc-Failures
Max-MQCs-Inuse
Alloc-Seg-Calls
Info-Calls
UCL-Max
TNS-Busy-Time
Comp-Traps
Abort-Trans
Expand Configuration and Management Manual—523347-008
20-26
45.73 %
48.13
315 #
2 #
8 #
144.37
33,000
Tuning
Using Measure
CPU Entity
The CPU entity should be measured with the PROCESS entity to allow a more
accurate estimate of processor use to be derived and to give guidance for load
balancing. Example 20-5 is an example of a CPU entity display.
Example 20-5. CPU Entity Display
Cpu 2 NSR-W
Memory MB
128
Local System \TAHITI
Init Lock Pgs
144
PCBs
1800
From
7 Feb 1997, 12:03:32
Cpu-Busy-Time
Cpu-Qtime
Mem-Qtime
Dispatches
Process-Ovhd
Disc-IOs
Transactions
Page-Requests
Ending-Free-Mem
Ending-UDS
Ending-UCL
Accel-Busy-Time
TNSR-Busy-Time
3.51 %
0.04 #
88.91
4,856
1,523
1,427
0.02
2.47
#
#
#
%
%
Swaps
Cpu-Qlen-Max
Mem-Qlen-Max
Intr-Busy-Time
Send-Busy-Time
Cache-Hits
Response-Time
Page-Scans
Ending-UCME
Ending-SDS
Ending-SCL
TNS-Busy-Time
Comp-Traps
Mem Pages
8192
Pg Size
16384 Bytes
For 43.6 Seconds
23 #
5 #
1.02 %
594 #
4,294,967 K
0.01 %
46.58
Determining Processor Use
To determine the processor use of an Expand line-handler process, you must add a
fraction of the Intr-Busy-Time count from the processor where the Expand line-handler
process is running to the Cpu-Busy-Time value for the Expand line-handler process.
This fraction can be estimated using the following formula:
(PROCESS-Dispatches / CPU-Dispatches) * (Intr-Busy-Time - Send-Busy-Time)
PROCESS-Dispatches
is the value shown in the Dispatches counter of the PROCESS entity display.
CPU-Dispatches
is the value shown in the Dispatches counter of the CPU entity display.
Intr-Busy-Time
is a counter shown in the CPU entity display.
Send-Busy-Time
is a counter shown in the CPU entity display.
For example, you can use the following values from the PROCESS entity and CPU
entity displays shown above to determine the processor use of process $PATHF
running in processor 2:
Expand Configuration and Management Manual—523347-008
20-27
Tuning
•
•
•
•
•
Measuring Passthrough Traffic
CPU-Busy-Time = 31.20%
Process Dispatches = 48.13
CPU Dispatches = 51.00
CPU Intr-Busy-Time = 13.24%
CPU Send-Busy-Time = 4.64%
Using the formula shown above, the adjusted processor use for $PATHF is 39.32%, as
reached from the following formula:
31.20 + ((48.13 / 51.00) * (13.24 - 4.64)) = 39.32
For a complete accounting of Expand line-handler process overhead, the network
control process ($NCP) and Expand manager process ($ZEXP) should also be
measured. $NCP activity is relatively fixed and depends on network size, configuration,
and the quality of the transmission lines. Because the activity of $NCP is not directly
related to the amount of traffic, it is not necessary to account for it when sizing or
tuning a path.
Measuring Passthrough Traffic
Although passthrough traffic is reported in the SYSTEM entity (SENT-FWD and RCVDFWD counters), Measure does not directly account for the source and destination of
passthrough traffic when examining a path. An Expand line-handler process only sees
the node to which it is connected. The only way to map the passthrough traffic
accurately is to know the topology of your network and to measure each Expand linehandler process on each node. This is usually not feasible or necessary for most
tuning efforts.
Setting Measurement Intervals
It is important to set appropriate measurement intervals when using Measure to
characterize Expand network performance. For example, if you want to define the peak
traffic of a path at a critical hour during the day, you should take a sample at short
intervals of perhaps 1-minute during the sample period. To gather information for a
daily traffic profile, you should take a sample every 30 minutes during a 24-hour period.
Regardless of your objectives, you should make sure that you take samples often
enough so that you do not allow Measure’s counters to overflow.
You can simultaneously measure the same Expand entities with more than one interval
using two separate measurement files. An effective management strategy is to sample
network performance at long intervals (possibly every hour on a regular basis) while
simultaneously taking short-interval snapshots during critical periods for a particular
study.
Note. Measuring adds no burden to the measured entity; the counters maintained by the
system are sampled by Measure without affecting the measured process.
Expand Configuration and Management Manual—523347-008
20-28
Tuning
Tuning Examples
Tuning Examples
The figures shown in this subsection are based on actual Expand networks. These
figures demonstrate simple methods for capturing and analyzing data, estimating
results, and adjusting tunable Expand network components. All of the data shown was
captured by Measure or SCF and then extracted manually and entered in spreadsheet
programs.
Example 1: Changing Packet Size
The following example illustrates one simple method to determine if altering a path’s
packet size can reduce processor overhead and improve bandwidth utilization on
communications lines. Data for this type of analysis is available using Expand
subsystem SCF PATH STATS command or the Measure NETLINE utility. Measure is
preferred for long-term studies, while data shown by SCF PATH STATS is resettable
and can be used to log statistics for any range of time. Example 20-6 is an example of
an SCF PATH STATS display.
Example 20-6. SCF PATH STATS Display
-------------------- LEVEL 4 MESSAGE HISTOGRAM --------------------------<=
64 ..
71027
<= 128 ..
25609
<= 256..
4211
<= 512 ..
1676
<= 1024 ..
1466
<= 2048..
370
<= 4096 ..
179
> 4096 ..
2288
-------------------- LEVEL 4 / LEVEL 3------------Average--------Average--Packets
Forwards
Links
Packets/Block
Bytes/Block
Sent
230144
0
24888
1.0
238
Rcvd
94921
0
28559
1.0
178
L4 Packets Discarded.........
0
The key statistics in Example 20-6 are the Level 4/Level 3 Sent and Rcvd packets and
links. Each link reflects a network request. Each request requires at least one packet to
be sent, plus one to be received. Both packets are seen in the history.
In this example, the frame size (FRAMESIZE modifier) was 132 words and the variable
packet size (PATHPACKETBYTES modifier) was not available. The extended packet
format was enabled (L4EXTPACKETS_ON modifier), which means that 75 percent of
each packet was Expand subsystem overhead. Assuming 192 bytes of user data per
packet, the average message sizes are easily calculated using the following formula:
average_message_size = (packets / links) * 192
The following average message sizes are derived from the data shown:
Average message size sent:
(230144/24888) * 192
= 9.25 * 192
= 1776
Average message size received:
(94921/28559) * 192
= 3.32 * 192
= 638
Average overall message size:
(325065/53477) * 192
= 6.08 * 192
= 1167
Expand Configuration and Management Manual—523347-008
20-29
Tuning
Example 1: Changing Packet Size
These average message sizes suggest the use of a larger packet size on the path.
Changing the packet size to 1024 bytes would greatly reduce the processor cost per
request and reduce the Expand subsystem overhead required per message.
Messages up to 960 bytes will fit within a 1024-byte packet (with 64 bytes of
overhead). The following compares the packets per link required for 256-byte packets
(frame size equal to 132 words) and 1024-byte packets:
256-Byte Packets
1024-Byte Packets
Messages Sent
(average message size=1776 bytes)
230144/24888 = 9.25
46043/24888 = 1.85
Messages Received
(average message size = 638 bytes)
94921/28559 = 3.32
28559/28559 = 1.0
Overall
325065/53477 = 6.08
74602/53477 = 1.4
These calculations suggest that it would be very effective to increase the Expand
packet size to 1024 bytes on this path. Expand subsystem processor cost could be
reduced significantly, probably to less than 50 percent of the previous Expand
subsystem processor cost. The savings would be in the processor cost per packet. The
per-message processor cost is a constant no matter what packet size is used since the
number of messages and the size of the messages is the same in both cases.
For messages sent, changing the packet size to 1024 bytes improves the packets-perlink ratio by about five times. Increasing the packet size to 2048 bytes could further
improve efficiency on the path (but this is not possible for all line types):
1024-Byte Packets
2048-Byte Packets
Messages Sent
(average message size=1776 bytes)
46043/24888 = 1.85
24888/24888 = 1.0
Messages Received
(average message size=638 bytes)
28559/28559 = 1.0
28559/28559 = 1.0
Overall
74602/53477 = 1.4
53477/53477 = 1.0
Increasing the packet size to 2048 bytes should increase efficiency slightly more since
it would only reduce the number of packets by an additional 40 percent, possibly
reducing Expand subsystem processor cost another 10 to 20 percent.
For each packet saved, 64 bytes of Expand header is no longer needed. The
percentage of bandwidth saved can be estimated. First, choose the busy direction. In
the example, the outgoing direction has the largest average message size (1776
bytes). If in doubt, select the direction where links times message size is greatest.
Calculate the bandwidths required for the 1024-byte packet size and the original 256byte size using the following formula:
average_message_size + (number_of_packets * 64)
The bandwidth used for 1024-byte packets would be
1776 + (2 * 64) = 1904 = 15323 bits/message
Expand Configuration and Management Manual—523347-008
20-30
Tuning
Example 1: Changing Packet Size
The bandwidth used for 256-byte packets would be
1776 + (10 * 64) = 2416 = 19328 bits/message
If the packet size is changed to 1024 bytes, only 79 percent of the bandwidth that was
previously used would be required. The bandwidth used for the 2048-byte packet size
would be
1776 + (1 * 64) = 1840 = 14720 bits/message
This would be 3 percent less than the bandwidth required for the 1024-byte packet
size.
Figure 20-6 shows a comparison of the bandwidths used for packets of 245, 1024, and
2048 bytes.
Figure 20-6. Packet Size/Bandwidth Comparison
Bits per
message
20000
15000
10000
5000
0
256
1024
2048
Packet Size
(Bytes)
VST029.vsd
Expand Configuration and Management Manual—523347-008
20-31
Tuning
Example 2: Reducing Passthrough Traffic
Example 2: Reducing Passthrough Traffic
It is common for the role of a node in an Expand network to change over a period of
time. Example 20-7 shows a situation in which the routine, simple collection of
Measure SYSTEM entity data helped an operations staff discover that certain nodes in
the network had become switches—that is, their resources were used primarily for
passthrough traffic. Further investigation showed that the simple rerouting of
communications lines would help to recover some processor resources and free
controllers to be used elsewhere, perhaps in more stressed network paths.
Measuring Passthrough Traffic on a Single Node
Example 20-7 shows a summary of Measure SYSTEM entity data on a node called
\JUICE. The data was captured by Measure, placed in a structured file, and then
formatted with Enform.
The SYSTEM data allows you to compare the number of Expand frames transferred
between a node and its neighbors to those that are simply forwarded or passed
through to other nodes. Passthrough traffic is shown in the SENT-FWD and RCVDFWD counters. Total passthrough traffic is shown in the TOTAL FORWARD column.
Notice that the source and destination of passthrough traffic cannot be identified from
Measure data.
Example 20-7. Passthrough Traffic From Measure SYSTEM Counters on \JUICE
<========Expand FRAMES============> TOTAL TOTAL
SYSTEM
LINKS
SENT RECEIVED SENT-FWD RCVD-FWD DIRECT FORWARD
===================================================================
\TOPPER
9816
21605
20549
604067
580325
42154 1184392
\TONY
98328
292025
386625
294042
310158 678650 604200
\TRIGGR
46
177
140
123022
85795
317 208817
\SCOUT
24779
51396
55189
102819
2160 106585 104979
\FURY
10529
21725
23774
50291
50734
45499 101025
By comparing the total DIRECT frames to the total FORWARD frames, you can
determine that \JUICE is used primarily as a switch in the network among \TOPPER,
\TONY, and \TRGGR. Ninety-seven percent of the data (1,184,392 frames, as shown
in the TOTAL FORWARD column) sent to \JUICE from \TOPPER was passed on to
other nodes.
Similar measurements made on \TOPPER and \TONY would show that all the frames
forwarded through \JUICE to and from \TONY went to \TOPPER. About 300,000 bytes
were received from \TONY and sent to \TOPPER, and about 300,000 bytes were
received from \TOPPER and sent to \TONY. As a result, \JUICE is spending more time
processing passthrough traffic between \TOPPER and \TONY than it is sending direct
traffic.
Making a direct connection between \TONY and \TOPPER would eliminate 600,000
frames of passthrough traffic on \JUICE and would result in a 40 percent reduction in
unnecessary switched traffic. Additional benefits would include a reduction in the
Expand Configuration and Management Manual—523347-008
20-32
Tuning
Example 2: Reducing Passthrough Traffic
number of processors, communications devices, and communications links used on
\JUICE as well as in the network.
Measuring Passthrough Traffic in an Entire Network
Example 20-8 shows another step in the complete analysis of passthrough traffic in an
Expand network. In this example, data taken from SCF is used to compute the total
network overhead of passthrough traffic for each source and destination at one node.
This single-node analysis could be extended to all nodes in a network.
Note. The table in Example 20-8 was prepared by combining information from Expand
subsystem SCF PATH STATS and PROBE commands and then manipulating the data with a
spreadsheet. The STATS command showed the traffic, while the PROBE command showed
the number of hops. Example 20-8 is an illustration of one simple technique for deriving a
thorough understanding of network performance from standard, readily available
instrumentation.
Example 20-8. Passthrough Traffic in a Network
Local System \HERE
Frames
%
Send % Send
Rcv
% Rcv
Remote
Msgs
Rcvd
Frames Frames Total Pass Pass
Pass Pass
System
Sent
Sent
Rcvd
Rcvd
Hops
Thru Thru
Thru Thru
---------------------------------------------------------------------------\OAHU
40856
87030 81732 9.87%
4
522180 10.14% 490392 14.37%
\CANTON 39259
79444 78637 9.50%
4
476664 9.25% 471822 13.83%
\SAIPAN 10438
76652 77156 9.32%
1
0 0.00%
0 0.00%
\WAKE
21888
90266 72997 8.82%
1
0 0.00%
0 0.00%
\MAUI
36327
73565 72830 8.80%
4
441390 8.57% 436980 12.81%
\HOME
33113
69507 66592 8.04%
4
417042 8.10% 399552 11.71%
\UIST
32536
67577 64460 7.79%
4
405462 7.87% 386760 11.33%
\ROSS
10401
28964 62856 7.59%
2
57928
1.12% 125712 3.68%
\ATTU
24123 113862 48640 5.87%
5
910896 17.68% 389120 11.40%
\ARAN
15023
42482 30128 3.64%
5
339856 6.60% 241024 7.06%
\JERSEY
3
55901 25063 3.03%
1
0 0.00%
0 0.00%
\BLOCK
4222
25134 23663 2.86%
1
0 0.00%
0 0.00%
\ALCA
269
56364 22189 2.68%
1
0 0.00%
0 0.00%
\TRAZ
3
51155 20649 2.49%
1
0 0.00%
0 0.00%
\KISKA
8236
71395 16628 2.01%
3
285580 5.54%
66512 1.95%
\HONSHU
7364
38922 15157 1.83%
4
233532 4.53%
90942 2.67%
\NOMAN
6938
14883 13932 1.68%
4
89298 1.73%
83592 2.45%
\MOGMOG
4603
27432 10078 1.22%
4
164592 3.19%
60468 1.77%
\CONEY
3229
32742
7161 0.86%
4
196452 3.81%
42966 1.26%
\KARGH
2706
26766
6313 0.76%
4
160596 3.12%
37878 1.11%
\ARMAGH
2617
27866
5568 0.67%
5
222928 4.33%
44544 1.31%
\GEDDON
2660
28414
5504 0.66%
5
227312 4.41%
44032 1.29%
========================================================================
Total
306814 1186323 827933 100% 71
5151708 100% 3412296
100%
Example 20-8 shows the true overhead produced by passthrough traffic for an entire
network. The route between \OAHU and \HERE consists of four hops because three
intermediate nodes and six Expand line-handler processes handle every message
between \OAHU and \HERE. For the network as a whole, 75 percent of the processor
overhead for traffic between \OAHU and \HERE is handled by the intermediate nodes.
Expand Configuration and Management Manual—523347-008
20-33
Tuning
Example 2: Reducing Passthrough Traffic
A more efficient routing scheme could be attained by installing a new path between
\OAHU and \HERE. By directly connecting \OAHU and \HERE, applications on
intermediate nodes would gain better response time, overall transaction overhead
would be reduced, circuit reliability would be greatly improved, the number of
retransmissions due to Layer 4 timeouts and line failures would be reduced, and
network management overhead would be eased.
The type of analysis and subsequent tuning shown in this example is not always
possible because few networks can be fully connected or meshed to eliminate
passthrough traffic. However, routinely studying simple summaries such as this one
and accurately calculating the true overhead produced by a multiple-hop circuit often
reveals that the cost of additional communications lines is more than offset by benefits
such as those cited above. This is particularly true in the United States, where the cost
of long communications links is decreasing.
Expand Configuration and Management Manual—523347-008
20-34
21
Troubleshooting
To quickly and efficiently identify and resolve network problems, HP recommends that
you use a standard network troubleshooting methodology. This methodology should
consist of the following elements:
•
•
•
•
•
•
Understanding Your Network on page 21-1
Collecting Network Information on page 21-1
Identifying Network Problems on page 21-3
Resolving Specific Network Problems on page 21-11
Reporting Network Problems on page 21-31
Resolving Common Network Problems on page 21-33
This section explains each of the elements of the troubleshooting methodology and
shows you how to use it to resolve common Expand subsystem problems.
Note. ServerNet/FX adapter subsystem and FOX ring troubleshooting information are
provided in the ServerNet/FX Adapter Configuration and Management Manual.
Understanding Your Network
A good understanding of the Expand subsystem and the normal operation of your
network are the most crucial elements in problem resolution. An understanding of the
operation of your own network should be based on:
•
•
•
Knowledge of the network design and configuration of each node in the network
Knowledge of the design and purpose of network applications
Information gathered using HP utilities during routine network checks
Collecting Network Information
This subsection describes the tools and commands provided to help you become
familiar with the normal operation of your network.
EMS
The Event Management Service (EMS) is a standard Distributed Systems
Management (DSM) interface that provides event collection, logging, and distribution
facilities. EMS messages for Expand are described in the Operator Messages Manual.
Expand Configuration and Management Manual—523347-008
21-1
Troubleshooting
SCF
SCF
The Subsystem Control Facility (SCF) interface to the Expand subsystem provides
several commands to help you determine the normal operation of Expand line-handler
processes.
The SCF STATS command displays Layer 4 and Layer 2 statistical information. The
SCF STATUS command displays information about the status of an object, such as its
state (STOPPED, STARTING, or STARTED).
The SCF LISTDEV command is useful for identifying system components and devices
including Expand line-handler processes and the network control process ($NCP). By
using the TYPE identifier in the SCF LISTDEV command, you can display specific
information about Expand subsystem components. Table 21-1 lists the TYPE identifiers
you can use to show information about Expand subsystem components and related
subsystems.
Table 21-1. LISTDEV TYPE Identifiers
TYPE Identifier
Process Description
63
Expand line-handler processes and Expand manager process ($ZEXP)
62
Network control process ($NCP)
64
ServerNet monitor process ($ZZSCL)
27
FOX monitor process ($ZZFOX)
61
X25AM processes
48
NonStop TCP/IP processes
45
QIO Monitor process (QIOMON)
Additional information about Expand SCF commands is provided in Section 19,
Managing the Network. Syntax information for SCF commands is provided in
Section 15, Subsystem Control Facility (SCF) Commands.
Measure
Measure is an HP tool for monitoring the performance of NonStop S-series servers. In
an Expand network, Measure determines if the network is contributing to a
performance problem. Additional information about Measure is provided in Section 20,
Tuning.
Measure is described in the Measure User’s Guide.
ASAP
The Availability Statistics and Performance (ASAP) monitoring tool provides graphical
and tabular displays of system and network object performance, object state, and
entity threshold information. The Availability Statistics and Performance Extension
(ASAPX) product integrates and extends ASAP monitoring capabilities to single and
Expand Configuration and Management Manual—523347-008
21-2
Troubleshooting
Identifying Network Problems
multi-node application environments. For more information about ASAP, refer to the
following manuals: ASAP Client Manual, ASAP Server Manual, ASAP Extension
Manual, and ASAP Migration Guide for NSX and OMF Users.
Identifying Network Problems
There are a number of sources from which to obtain information to identify a network
problem. Many of these sources are the same as those used to verify normal system
operation.
When a network problem occurs, usually more than one problem is reported (for
example, the user may encounter a file-system error at the same time that an event
message is reported). You can organize network problems into a hierarchy of entities,
as shown in Figure 21-1. When you begin to identify a network problem, it is usually
best to determine commonalities between all of the errors reported beginning with the
lowest layers.
Figure 21-1. Network Problem Hierarchy
User
Application
End System
Route
Path
Lines
VST027.vsd
This subsection contains examples that show how you can use the following sources
to identify a problem:
•
•
User Complaints
SCF Commands
Note. Refer to the discussion of Measure in the Measure User’s Guide for information about
interpreting performance information produced by tools such as Measure and ASAP.
Expand Configuration and Management Manual—523347-008
21-3
Troubleshooting
User Complaints
User Complaints
Most troubleshooting starts with user complaints, which can result from either
application or hardware problems. The best approach is always to check the obvious
first. For example:
•
•
•
Were any error messages returned? If so, what are they?
Did the user use the correct command syntax when accessing resources through
the network?
Was the complaint subjective (for example, slow response)? Were the user’s
expectations reasonable?
SCF Commands
SCF can be used to display information about Expand line-handler processes and FOX
rings. This subsection describes the most useful SCF commands for troubleshooting.
LISTDEV Command
The SCF LISTDEV command can be used to verify that system processes are active.
Table 21-2 shows how to verify system processes using the SCF LISTDEV command.
Table 21-2. Verifying Processes Using the SCF LISTDEV Command
Process to Verify
Default Process Name
Command Syntax
Network control process
$NCP
LISTDEV $NCP
or
LISTDEV TYPE 62
Expand manager process
$ZEXP
LISTDEV $ZEXP
or
LISTDEV TYPE 63
ServerNet monitor process
$ZZSCL
LISTDEV $ZZSCL
or
LISTDEV TYPE 64
FOX monitor process
$ZZFOX
LISTDEV $ZZFOX
or
LISTDEV TYPE 27
A specific Expand line-handler
process
Not applicable
LISTDEV $device_name
All Expand line-handler
processes
Not applicable
LISTDEV TYPE 63
or
LISTDEV EXPAND
Expand Configuration and Management Manual—523347-008
21-4
Troubleshooting
SCF Commands
Example 21-1 shows an SCF LISTDEV display produced by a LISTDEV TYPE 63
command.
Example 21-1. SCF LISTDEV Display
LDev Name
PPID
BPID
Type
26
66
68
70
71
87
88
89
124
2,13
2,14
1,18
2,12
2,11
2,10
2,13
2,13
1,23
3,13
3,12
0,17
3,14
3,15
3,16
3,13
3,13
0,23
(63,1 )
(63,6 )
(63,0 )
(63,3 )
(63,0 )
(63,5 )
(63,6 )
(63,6 )
(63,30)
$PBAL4
$A10
$IPCOW
$FOXCOW
$EX25COW
$B30S
$B21
$B20
$ZEXP
RSize Pri Program
0
12
3
1
12
12
12
12
132
199
199
199
199
199
199
199
199
180
\TAHITI.$SYSTEM.T9057.LHOBJ
\TAHITI.$SYSTEM.SYS01.LHOBJ
\TAHITI.$SYSTEM.SYS01.LHOBJ2
\TAHITI.$SYSTEM.SYS01.LHOBJ2
\TAHITI.$SYSTEM.SYS01.LHOBJ
\TAHITI.$SYSTEM.SYS01.LHOBJ
\TAHITI.$SYSTEM.T9057.LHOBJ
\TAHITI.$SYSTEM.T9057.LHOBJ
\TAHITI.$SYSTEM.SYS01.OZEXP
Expand Subsystem SCF Commands
Table 21-3 lists the Expand subsystem SCF commands that are most helpful when
attempting to identify Expand subsystem problems.
Table 21-3. Identifying Problems With Expand Subsystem SCF Commands
Command
Use
STATS $device_name
Provides detailed statistical data, most of which can be
reset.
STATUS $device_name
Displays the dynamic state of the object, along with
modifiable information.
INFO PROCESS $NCP, LINESET
Verifies path and link state, checks logical device
(LDEV) numbers, and logs file-system error messages.
INFO PROCESS $NCP, NETMAP
Displays the nodes currently connected, with a listing
of the current routing data.
PROBE PROCESS $NCP
Displays status information about the intermediate
nodes in a path and displays the typical time to each
destination node.
Example 21-2 and Example 21-3 show example SCF STATS and SCF STATUS
displays. The U-Frames counter in the SCF STATS command display for a SWAN
Concentrator line shows the number of unsequenced or nonsequenced frames sent
and received by the Expand line-handler process. This counter may be high during line
setup; a large number of U-frames at any other time may indicate a fatal problem. (The
U-Frames counter is highlighted in bold type.)
Note. You should reset SCF statistics using the RESET command after starting a system or
line or resolving a problem.
Expand Configuration and Management Manual—523347-008
21-5
Troubleshooting
SCF Commands
Example 21-2. SCF STATS Display
3-> stats line $b30s
EXPAND
Stats LINE $B30S, PPID ( 2,
10), BPID ( 3,
16)
Resettime... FEB 18,1997 10:38:12
Sampletime... FEB 18,1997 15:32:36
---------------- LEVEL 2 -----------------I-Frames
S-Frames
U-Frames
Sent
40651
59229
2
Rcvd
17053
50970
2
------------------------ LEVEL 2
SABM
DISC
Sent
1
0
Rcvd
1
0
Sent
Rcvd
RNR
0
0
DETAIL ----------------------------------UA
DM
CMDR
RR
1
0
0
59229
1
0
0
50969
REJ
0
0
SREJ
0
0
I-FRM
40651
17053
I-FRM(P)
0
0
---------------------------- DRIVER ---------------------------------------Total Frms..
0 Line Quality..
100 No Buffer...
0
Err Frms....
0 BCC Errs......
0 Modem Errs..
0
Rcv OverRun
+0
------------------------- CLIP SPECIFIC -----------------------------------FCS Errs....
0 Addr Errs.....
0 Length Errs.
0
Rcv Abort...
0 Timeout.......
0 No Buffer...
0
CTS State...
OFF DSR State.....
OFF DCD State...
OFF
The SCF STATUS command displays in Example 21-3 show you how to use the
detailed (DETAIL option) version of the STATUS PATH command to determine the
logical device (LDEV) numbers of the lines within a multi-line path. In the example, the
path logical device is named $PBAL4 and consists of two lines with LDEVs 88 and 89.
SCF STATUS LINE commands are used to determine the status of each line in the
path.
Example 21-3. SCF STATUS Display
8-> status path $pbal4,detail
EXPAND
Detailed Status PATH $PBAL4
PPID........ ( 2,
13)
BPID........... ( 3,
State.......
STARTED
Number of Lines..
Trace Status
OFF
Superpath
Line LDEVs..
88
89
13)
2
OFF
9-> status line $88
EXPAND
Name
$B21
Status LINE
State Status
STARTED READY
PPID
2, 13
BPID
3, 13
CIU-Path
A
ConMgr-LDEV
30
PPID
2, 13
BPID
3, 13
CIU-Path
A
ConMgr-LDEV
30
10-> status line $89
EXPAND
Name
$B20
Status LINE
State Status
STARTED READY
Expand Configuration and Management Manual—523347-008
21-6
Troubleshooting
SCF Commands
The SCF INFO PROCESS $NCP LINESET command is useful for displaying the
status of a selected path and the lines in that path. The SCF INFO PROCESS $NCP,
LINESET command also displays the current file-system error. Example 21-4 shows an
example of an SCF INFO PROCESS $NCP, LINESET display.
Example 21-4. SCF INFO PROCESS $NCP, LINESET Display
-> INFO PROCESS $NCP, LINESET
EXPAND
Info
PROCESS
LINESETS AT \NODEA
LINESET
NEIGHBOR
1 S
\NODEB
(082)
$NCP
, LINESET
(117) #LINESETS=7 TIME:
LDEV
122
2 S
\NODEB
(082)
123
3 S
\NODEB
(082)
121
4
\NODEB
(082)
131
5
\NODEB
(082)
125
6
\NODEF
(247)
132
7
\NODEF
(247)
175
TF
PID
LINE
1 ( 1, 334)
1
1 ( 0, 333)
1
1 ( 0, 332)
1
-- -- ----1
3 ( 2, 271)
1
-- -- ----1
-- -- ----1
2
3
4
FEB 24,2003 13:55:04
LDEV
STATUS
122
READY
123
READY
121
READY
FileErr#
131 NOT READY (066)
125
READY
132 NOT READY (066)
212
254
256
259
NOT
NOT
NOT
NOT
READY
READY
READY
READY
(066)
(066)
(066)
(066)
Table 21-4 lists and describes the file-system error numbers that are most commonly
reported by the SCF INFO PROCESS $NCP, LINESET command.
Table 21-4. Common File-System Errors (page 1 of 2)
Error
Cause
Recovery
66
This error indicates that the line
was aborted or was never
started.
If the communications line interface processor
(CLIP) remains STOPPED, use the following
SCF commands:
ABORT LINE $device_name
START LINE $device_name
124
This error can occur when you
attempt to start a line. The
causes of this error differ
depending on the type of line.
If error 124 persists, there may
be a hardware problem.
The recovery depends on the cause of the
error. If the error does not persist, no action is
necessary. However, if the error does persist, a
hardware error may be indicated and you
should contact your HP representative.
Note. Detailed information about network-related file-system errors is provided in the Operator Messages
Manual.
Expand Configuration and Management Manual—523347-008
21-7
Troubleshooting
SCF Commands
Table 21-4. Common File-System Errors (page 2 of 2)
Error
Cause
Recovery
140
This error indicates that the
Expand line has been
disconnected. The cause could
be a problem with modem-tosystem communications or with
a phone line, a cable, or an X.25
connection.
Examine the physical connections and modem
settings to ensure that cables are plugged into
the correct line interface unit (LIU).
For IP, ATM, FOX, and
ServerNet lines, this error
usually means that the
ASSOCIATEDEV line modifier is
incorrectly configured, or an
error in communication with the
local ASSOCIATEDEV process
(TCPIP, ATM, $ZZFOX, or
$ZZSCL).
Check the configuration of the
ASSOCIATEDEV line modifier, if an IP, ATM,
FOX, or ServerNet line is involved.
Check the CPU that the TCP/IP process is
running on.
Check the access list of the SAC to make sure
that the line-handler process can access the
SAC.
164
This error may be generated
when you attempt to start a
SWAN direct or satellite line. It
means a DISC (disconnect)
frame was received from the
remote system.
The line should recover by itself when this error
is seen, so no recovery is required unless the
problem persists for more than one minute. If
the error persists, a hardware problem may be
indicated. Examine the log file and contact your
HP representative.
248
This error is often generated
when a line is started. The line is
electrically operational, but data
communications with the
neighbor node have not yet
occurred.
If the neighbor Expand line-handler process
has not yet started, use the Expand subsystem
SCF START command to start the line-handler
process.
Possible causes include the
neighbor Expand line-handler
process has not yet started; the
NEXTSYS modifier at the
neighbor node does not match;
there is a FRAMESIZE
mismatch.
If the NEXTSYS or FRAMESIZE modifier is
incorrect, correct it using the WAN subsystem
SCF ALTER DEVICE command.
Note. Detailed information about network-related file-system errors is provided in the Operator Messages
Manual.
Expand Configuration and Management Manual—523347-008
21-8
Troubleshooting
SCF Commands
The SCF INFO PROCESS $NCP, NETMAP command is useful for displaying the
current routing data. Example 21-5 shows a sample display of the SCF INFO
PROCESS $NCP, NETMAP command. Asterisks indicate the best-path route. A plus
sign (+) instead of an asterisk (*) would indicate that the Expand subsystem is
attempting to connect or reconnect a path.
Example 21-5. SCF INFO PROCESS $NCP, NETMAP Display
-> INFO PROC $NCP,NETMAP
EXPAND
Info
PROCESS
$NCP, NETMAP
NETMAP AT \NODEA (117) #LINESETS=7 TIME:
FEB 24,2003 13:54:46
SYSTEM
82 \NODEB
TIME
1(01)&
inf(--)
(DISTANCE) BY
1(01)&
1(01)*
PATH
inf(--)
3(01)
inf(--)
123 \NODEC
4(02)
inf(--)
4(02)
inf(--)
6(02)
inf(--)
[
[
6]
7]
151 \NODEG
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
[
[
6]
7]
160 \NODED
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
[
[
6]
7]
247 \NODEF
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
inf(--)
[
[
6]
7]
254 \NODEE
7(03)*
inf(--)
7(03)
7(03)
inf(--)
9(03)
inf(--)
[
[
6]
7]
4(02)*
INDEX
[ 6]
[ 7]
--------------------------------------------------------------LINESETS AT \NODEA
LINESET
NEIGHBOR
1 S
\NODEB
(082)
LDEV
122
2 S
\NODEB
(082)
123
3 S
\NODEB
(082)
121
4
\NODEB
(082)
131
5
\NODEB
(082)
125
6
\NODEF
(247)
132
7
\NODEF
(247)
175
(117) #LINESETS=7
TF
PID
LINE
1 ( 1, 334)
1
1 ( 0, 333)
1
1 ( 0, 332)
1
-- -- ----1
3 ( 2, 271)
1
-- -- ----1
-- -- ----1
2
3
4
LDEV
STATUS
122
READY
123
READY
121
READY
FileErr#
131 NOT READY (066)
125
READY
132 NOT READY (066)
212
254
256
259
NOT
NOT
NOT
NOT
READY
READY
READY
READY
Expand Configuration and Management Manual—523347-008
21-9
(066)
(066)
(066)
(066)
Troubleshooting
Problem Check-List Summary
The SCF PROBE PROCESS, $NCP command is useful for displaying the intermediate
nodes in a path and the typical time to each destination node. Example 21-6 shows a
sample display of the SCF PROBE PROCESS, $NCP command.
Example 21-6. SCF PROBE PROCESS, $NCP Display
6-> PROBE PROCESS $NCP, AT \NODEA, TO \NODEC
EXPAND
Probe PROCESS
$NCP
NETPROBES AT \NODEA (016)
113
TIME: 17 FEB 1997, 10:19:13
\NODEC - \NODEW - \NODER - \NODET - \NODEM - *
(0086)
The (0086) value displayed in this example is calculated in hundredths of seconds
(centiseconds); a time of 0086 is .86 seconds.
Problem Check-List Summary
Table 21-5 summarizes how to use HP utilities to identify network problems.
Table 21-5. Network Problem Check List
Utility
Information Produced
EMS
Events collected by the Event Management Service (EMS) can be
viewed using either the OSM or TSM event viewers.
SCF
The Subsystem Control Facility (SCF) catches syntax errors, value
ranges, and incompatible selections in the Expand subsystem
configuration. However, the Expand subsystem usually detects other
types of configuration errors after system load, not when an SCF
command is used.
The SCF LISTDEV or SCF STATUS command can be used to verify
that all Expand line-handler processes are active. You can also use the
SCF LISTDEV command to ensure that the network control process
($NCP) is running.
Measure
Measure can be used to make a detailed study of a particular nodes
Expand line-handler processes. You can characterize Expand network
traffic by measuring certain Measure entities.
ASAP
The Availability Statistics and Performance (ASAP) monitoring tool
provides graphical and tabular displays of system and network object
performance, object state, and entity threshold information. The
Availability Statistics and Performance Extension (ASAPX) product
integrates and extends ASAP monitoring capabilities to single and
multi-node application environments.
Expand Configuration and Management Manual—523347-008
21-10
Troubleshooting
Resolving Specific Network Problems
Resolving Specific Network Problems
This subsection provides checklists for solving the following specific network problems:
•
•
•
•
•
•
•
$NCP Problems
Expand Line-Handler Process Problems
SWAN Concentrator Problems
WAN Subsystem Problems
Expand-Over-X.25 Problems
Expand-Over-IP Problems
Multi-CPU Path Problems
$NCP Problems
Table 21-6 lists SCF commands that are useful for diagnosing problems with $NCP.
Table 21-6. Identifying $NCP Problems With SCF Commands
Command
Use
STATUS DEVICE $ZZWAN.#NCP
Displays the state of $NCP.
START DEVICE $ZZWAN.#NCP
Starts $NCP.
INFO DEVICE $ZZWAN.#NCP
Displays configuration information for $NCP.
or
INFO PROCESS $NCP
CPUS
Provides information about the number of nodes
known by the local node.
INFO PROCESS $NCP,
CONNECTS
Displays the systems that are connected or
connecting, and only the entry for which the
connection is established. If the path is a multi-CPU
path (superpath), the CONNECTS option displays all
of the paths in the multi-CPU path. It is basically a
summary of the NETMAP command, but shows only
the connected entries.
INFO PROCESS $NCP, LINESET
Displays the status of a selected path and the status
of started lines that make up that path.
INFO PROCESS $NCP, NETMAP
Provides best-path route identification, routing data
for the best path, and a list of the nodes currently
seen by the local node.
INFO PROCESS $NCP, PATHSET
Displays the NCP pathmap information, similar to the
LINESET option but in a different format. This format
displays both the line-handler LDEV and name, as
well as the other information already in the LINESET
option.
INFO PROCESS $NCP, RPT
Displays the information kept in the reverse pairing
table (RPT) for each multi-CPU path on the selected
system.
Expand Configuration and Management Manual—523347-008
21-11
Troubleshooting
$NCP Problems
Table 21-6. Identifying $NCP Problems With SCF Commands
Command
Use
INFO PROCESS $NCP, SYSTEMS
Displays all known systems. If no connection is
established, the SYSTEMS option displays an infinite
time factor and hop count. The SYSTEMS option is
similar to the CONNECTS option, except that the
CONNECTS option displays only the systems
connected.
INFO PROCESS $NCP,
SUPERPATH
Displays the effective time factor (ETF), time factor
(TF), logical device (LDEV) number, and local and
remote processors for each path within each multiCPU path on the selected system.
PROBE PROCESS $NCP
Provides status information about the intermediate
nodes in a path and displays the typical time to each
destination node.
Expand Configuration and Management Manual—523347-008
21-12
Troubleshooting
Expand Line-Handler Process Problems
Expand Line-Handler Process Problems
Table 21-7 lists procedures to help you resolve Layer 4 and Layer 2 Expand linehandler process problems.
Note. You should be familiar with the Expand End-to-End protocol before attempting to
analyze Layer 4 and Layer 2 problems. The End-to-End protocol is described in Path Function
of the Expand Subsystem on page 18-13.
Table 21-7. Expand Line-Handler Process Problem-Resolution Procedures
Problem
Procedure
Expand Layer 4
(End-to-End)
protocol
The End-to-End protocol accepts packets for the line(s) from the local
node and passthrough packets destined for other nodes. The End-toEnd protocol also selects the line or manages the interface for the
X25AM subsystem, the SNAX/APN subsystem, the NonStop TCP/IP
subsystem, the Asynchronous Transfer Mode (ATM) subsystem, the
SWAN concentrator, or the ServerNet/FX adapter subsystem.
You can use the Expand subsystem SCF STATS PATH command to
obtain a detailed listing of the Layer 4 statistics.
Layer 4 statistics indicate Layer 4 checksum errors, buffer pool failures,
and out-of-sequence (OOS) errors. These errors can point to the
following problems:
•
•
•
Expand Layer 2
protocol
Inadequate buffer pool allocation
Excessive traffic causing activation of Layer 4 flow control
A high number of packets arriving on different lines out of sequence,
contributing to processing overhead
You can use the SCF STATS LINE command to examine Layer 2
statistics. Figure 21-1 (earlier in this section) is an example of an SCF
STATS LINE command.
Expand Configuration and Management Manual—523347-008
21-13
Troubleshooting
SWAN Concentrator Problems
SWAN Concentrator Problems
This subsection provides ServerNet wide area network (SWAN) concentrator
troubleshooting guidelines and identifies common SWAN concentrator problems.
Troubleshooting Check List
Use the check list provided in Table 21-8 to solve problems related to SWAN
concentrators.
Table 21-8. SWAN Concentrator Problem-Resolution Check List (page 1 of 2)
Task
Procedure
Check the SWAN concentrator.
To determine the state of a specific SWAN
concentrator, use the following WAN subsystem
SCF command:
STATUS ADAPTER $ZZWAN.#conc-name
where conc-name is the name of the SWAN
concentrator (ADAPTER object). To determine the
status of all the SWAN concentrators on a system,
use the following WAN subsystem SCF command:
STATUS ADAPTER $ZZWAN.*
If the SWAN concentrator is not operational, it must
be started. See the WAN Subsystem Configuration
and Management Manual for details.
Check the communications line
interface processors (CLIPs) on the
SWAN concentrator.
To determine the state of the CLIPs on a specific
SWAN concentrator, use the following SCF
commands:
STATUS SERVER $ZZWAN.#conc-name.1
STATUS SERVER $ZZWAN.#conc-name.2
STATUS SERVER $ZZWAN.#conc-name.3
where conc-name is the name of the SWAN
concentrator (ADAPTER object). If a CLIP is not
operational, it must be started. See the WAN
Subsystem Configuration and Management Manual
for details.
Expand Configuration and Management Manual—523347-008
21-14
Troubleshooting
SWAN Concentrator Problems
Table 21-8. SWAN Concentrator Problem-Resolution Check List (page 2 of 2)
Task
Procedure
Check the Ethernet paths configured
for each CLIP on the SWAN
concentrator.
To determine the state of the Ethernet paths
configured for each CLIP on a specific SWAN
concentrator, use the following SCF commands:
STATUS
STATUS
STATUS
STATUS
STATUS
STATUS
PATH
PATH
PATH
PATH
PATH
PATH
$ZZWAN.#conc-name.1.a
$ZZWAN.#conc-name.1.b
$ZZWAN.#conc-name.2.a
$ZZWAN.#conc-name.2.b
$ZZWAN.#conc-name.3.a
$ZZWAN.#conc-name.3.b
where conc-name is the name of the SWAN
concentrator (ADAPTER object). If an Ethernet path
is not operational, it must be started. See the WAN
Subsystem Configuration and Management Manual
for details.
Check the SWAN kernel code
version.
To display the version of the SWAN kernel code
installed on a SWAN concentrator, use the following
command to display the EMS log on your terminal:
EMSDIST CO $0, TY P, TE [#myterm]
Next, initiate a BOOTP sequence by resetting the
SWAN concentrator or by adding the SWAN
concentrator using WAN subsy