expand configuration and management manual (h06.21+, j06.10+)h20628. · expand configuration and...

Expand Configuration and Management Manual

Abstract

This manual describes how to plan, configure, manage, and troubleshoot the Expand subsystem on an HP Integrity NonStop™ BladeSystem and HP Integrity NonStop NS-series server. The Expand subsystem can 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 server. This manual includes detailed descriptions of SCF commands and modifiers used with the Expand subsystem.

Product Version

Expand H01

Supported Release Version Updates (RVUs)

This manual supports J06.10 and all subsequent J-series RVUs and H06.21 and all subsequent H-series RVUs, until otherwise indicated by its replacement publications.

Part Number Published

529522-013 February 2014

Document History Part Number Product Version Published

529522-008 Expand H01 June 2010

529522-009 Expand H01 August 2010

529522-010 Expand H01 August 2012

529522-011 Expand H01 February 2013

529522-012 Expand H01 April 2013


Legal Notices© Copyright 2014 Hewlett-Packard Development Company L.P.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Export of the information contained in this publication may require authorization from the U.S. Department of Commerce.

Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation.

Intel, Itanium, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Java is a registered trademark of Oracle and/or its affiliates.

Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the U.S. and other countries.

Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc.

OSF MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

OSF shall not be liable for errors contained herein or for incidental consequential damages in connection with the furnishing, performance, or use of this material.

© 1990, 1991, 1992, 1993 Open Software Foundation, Inc. This documentation and the software to which it relates are derived in part from materials supplied by the following:

© 1987, 1988, 1989 Carnegie-Mellon University. © 1989, 1990, 1991 Digital Equipment Corporation. © 1985, 1988, 1989, 1990 Encore Computer Corporation. © 1988 Free Software Foundation, Inc. © 1987, 1988, 1989, 1990, 1991 Hewlett-Packard Company. © 1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. © 1988, 1989 Massachusetts Institute of Technology. © 1988, 1989, 1990 Mentat Inc. © 1988 Microsoft Corporation. © 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc. © 1990, 1991 Siemens Nixdorf Informationssysteme AG. © 1986, 1989, 1996, 1997 Sun Microsystems, Inc. © 1989, 1990, 1991 Transarc Corporation.

This software and documentation are based in part on the Fourth Berkeley Software Distribution under license from The Regents of the University of California. OSF acknowledges the following individuals and institutions for their role in its development: Kenneth C.R.C. Arnold, Gregory S. Couch, Conrad C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. © 1980, 1981, 1982, 1983, 1985, 1986, 1987, 1988, 1989 Regents of the University of California.

Printed in the US

Expand Configuration and Management Manual

Glossary Index Examples Figures Tables

Legal Notices

What’s New in This Manual xxvii

Manual Information xxvii

New and Changed Information xxvii

About This Manual xxxiii

Who Should Use This Manual xxxiii

How This Manual Is Organized xxxiii

Related Documentation xxxvii

Notation Conventions xxxix

Abbreviations xliii

HP Encourages Your Comments xlv

Part I. Getting Started

1. Configuration Quick StartTask 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-3

Creating a Persistent Version of the Expand Manager Process 1-3


Task 3: Add the Expand Line-Handler Profile(s) 1-4


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-15


Task 5: Start the Expand Line-Handler Process 1-18

Establishing a Connection 1-18

Starting an Expand Path 1-18

Hewlett-Packard Company — 529522-013i

Contents 2. Expand Overview

Starting Lines in a Multi-Line Path 1-18

2. Expand OverviewNetwork Transparency 2-1

Interactive Access 2-1

Programmatic Access 2-2

Expand Subsystem and the NonStop Operating System 2-2

Multiple Communications Environments 2-5

Leased and Satellite Connections 2-5

X.25 Packet-Switched Networks 2-5

Systems Network Architecture (SNA) Networks 2-6

Internet Protocol (IP) Networks 2-6

Asynchronous Transfer Mode (ATM) Networks 2-6

ServerNet Clusters 2-6

Distributed Control 2-7

Automatic Message Routing 2-7

Passthrough Routing 2-7

Best-Path Routing 2-7

Priority Routing 2-8

Fault-Tolerant Operation 2-8

Network Management 2-8

Subsystem Control Facility (SCF) 2-9

Event Management Service (EMS) 2-9

Availability Statistics and Performance (ASAP) 2-9

Measure 2-9

OSM Interface 2-9

Online Expansion and Reconfiguration 2-10

Network Security 2-11

Remote Passwords 2-11

Enhanced Security Techniques 2-11

3. Planning a Network DesignSelecting 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

ServerNet Connections 3-6

Expand Configuration and Management Manual — 529522-013ii

Contents 4. Planning for ServerNet Clusters

Defining Paths Between Systems 3-7

When to Use a Single-Line Expand Line-Handler Process 3-7

When to Use a Multi-Line Path 3-7

When to Use a Multi-CPU Path 3-9

Selecting Special Features 3-11

Multipacket Frame Feature 3-11

Variable Packet Size Feature 3-11

Congestion Control Feature 3-12

Designing the Network Topology 3-12

Common Network Topologies 3-12

Topology Limitations 3-14

Creating a Network Diagram 3-15

4. Planning for ServerNet ClustersConfiguration Considerations for Expand and ServerNet Clusters 4-2

ServerNet Clusters Coexisting With ATM or IP Networks 4-3

Considerations for ServerNet Clusters Coexisting With ATM or IP 4-3

Examples of ServerNet Clusters Coexisting With ATM or IP 4-4

Part II. Configuring the Expand Subsystem

5. Configuration OverviewSummary of Configuration Steps 5-2

Creating a Profile 5-3

Creating Wide Area Network (WAN) Subsystem Devices 5-4

Starting the Expand Manager Process 5-4

6. Configuring the Network Control ProcessStep 1: Create a Profile for $NCP 6-1

ADD Profile Command 6-1

Example 6-2

Step 2: Create $NCP 6-2

ADD DEVICE Command 6-2

Considerations 6-3

Example 6-3

Step 3: Start $NCP 6-4

$NCP Modifiers 6-4

7. Configuring Direct-Connect and Satellite-Connect Lines

Expand Configuration and Management Manual — 529522-013iii

Contents 8. Configuring Expand-Over-IP 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) 7-3

ServerNet Wide Area Network (SWAN) Concentrator 7-4

Topology Considerations 7-4

Summary of Configuration Steps 7-5

Step 1: Find an Available WAN Line 7-5

Step 2: Create a Profile for the Line-Handler Process 7-7


Examples 7-8

Step 3: Create the Line-Handler Process 7-8


Considerations 7-10

Examples 7-10

Step 4: Start the Line-Handler Process 7-11

Step 5: Start the Line 7-11

Profile Modifiers 7-12

Modifiers for Special Features 7-12

PEXQSSWN and PEXQSSAT Modifiers 7-12

8. Configuring Expand-Over-IP LinesRequired Hardware and Software 8-2

QIO Subsystem 8-3


NonStop TCP/IPv6 Process 8-4

CIP Process 8-4

Redundancy in Ethernet Adapters 8-4


Asynchronous Transfer Mode (ATM) Subsystem 8-6

LAN or ATM Adapters or the CLIM 8-6



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-10

Creating an Ethernet SUBNET or ATM SUBNET 8-10

Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use 8-11

Expand Configuration and Management Manual — 529522-013iv

Contents 9. Configuring Expand-Over-ATM Lines

Select a SUBNET for NonStop TCP/IPv6 Use 8-11

Select a TCP6SAM Process 8-13

Creating an Ethernet Subnet 8-14

Step 1 (C): Select a Process and SUBNET for CIP Use 8-15

Select a CIPSAM Process 8-15

Obtain an IP Address to associate with your Expand Line- Handler Process 8-15

Step 2 (A): Identify an Available UDP Port Number 8-17

Step 2 (B): Identify an Available UDP Port Number for NonStop TCP/IPv6 Use 8-18

Step 2 (C): Identify an available UDP Port Number for CIP Use 8-20



Example 8-23



Considerations 8-26

Example 8-27



Add a Configured Tunnel for an Expand Line 8-28

Add a Configured Tunnel for an Expand Line for CIP 8-30


Recommended Modifiers 8-32


PEXQSIP Modifiers 8-33

9. Configuring Expand-Over-ATM LinesRequired Hardware and Software 9-2

QIO Subsystem 9-2

ATM Subsystem 9-3

SLSA Subsystem 9-3

ATM 3 ServerNet Adapter (ATM3SA) 9-3



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



Expand Configuration and Management Manual — 529522-013v

Contents 10. Configuring Expand-Over-X.25 Lines

Example 9-12



Considerations 9-16

Examples 9-16






PEXQSATM Modifiers 9-19

10. Configuring Expand-Over-X.25 LinesRequired Hardware and Software 10-2

X25AM Line-Handler Process 10-3

QIO Subsystem 10-3







Step 1: Add a NAM Subdevice to the X25AM Line 10-7

Considerations 10-7

Step 2: Start the X25AM Line 10-7

Step 3: Create a Profile for the Expand-Over-X.25 Line-Handler Process 10-8


Example 10-9

Step 4: Create the Expand-Over-X.25 Line-Handler Process 10-9


Considerations 10-11

Examples 10-11

Step 5: Start the Expand-Over-X.25 Line-Handler Process 10-12

Step 6: Start the Expand-Over-X.25 Line 10-12




X25AM Line-Handler Process Modifiers 10-14

PEXQSNAM Modifiers 10-14

Expand Configuration and Management Manual — 529522-013vi

Contents 11. Configuring Expand-Over-SNA Lines

11. Configuring Expand-Over-SNA LinesRequired Hardware and Software 11-2

SNAX/APN Line-Handler Process 11-3

QIO Subsystem 11-3







Step 1: Add the SNAX/APN Line 11-7

Considerations 11-7

Step 2: Add the LUs for the SNAX/APN Line 11-8

Considerations 11-8

Example 11-9

Step 3: Start the SNAX/APN Line 11-10

Step 4: Create a Profile for the Expand-Over-SNA Line-Handler Process 11-10


Example 11-11

Step 5: Create the Expand-Over-SNA Line-Handler Process 11-11



Examples 11-13

Step 6: Start the Expand-Over-SNA Line-Handler Process 11-14

Step 7: Start the Expand-Over-SNA Line 11-14




PEXQSNAM Modifiers 11-16

12. Configuring Expand-Over-ServerNet LinesRequired Hardware and Software 12-2

Expand Manager Process ($ZEXP) 12-3

External System Area Network Manager (SANMAN) 12-3

Message Monitor Process (MSGMON) 12-3

Network Access Method (NAM) 12-3

Network Control Process ($NCP) 12-4

Cluster Switch 12-4

Profile Products 12-4

Expand Configuration and Management Manual — 529522-013vii

Contents 13. Configuring Multi-Line Paths

ServerNet Cluster Monitor Process ($ZZSCL) 12-4

ServerNet Cluster Product 12-5

Wide Area Network (WAN) Subsystem 12-5

X and Y Fabrics 12-5



Configuring a ServerNet Node 12-7

Step 1: Create a Profile for the Expand-Over-ServerNet Line-Handler Process 12-8


Example 12-9

Step 2: Create a Device for the Expand-Over-ServerNet Line-Handler Process 12-9



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



PEXPSSN Modifiers 12-13

13. Configuring Multi-Line PathsConfiguration Overview 13-1

Configuration Considerations 13-2


Step 1: Create a Profile for the Path-Logical Device 13-3

ADD PROFILE Command 13-3

Step 2: Create a Profile for Each Line Type 13-4

ADD PROFILE Command 13-4

Step 3: Create a Path-Logical Device 13-6


Considerations 13-7

Step 4: Create the Line-Logical Devices 13-8



Step 5: Start the Path-Logical Device 13-13

Step 6: Start the Lines 13-14

Starting Specific Lines 13-14

Configuration Example 13-15

Expand Configuration and Management Manual — 529522-013viii

Contents 14. Subsystem Control Facility (SCF) Commands

Path-Logical Device Modifiers 13-16


PEXPPATH Modifiers 13-16

Line-Logical Device Modifiers 13-18

X25AM Process Modifiers 13-18

PEXQMSWN and PEXQMSAT Modifiers 13-18

PEXQMNAM Modifiers 13-20

PEXQMIP Modifiers 13-21

PEXQMATM Modifiers 13-22

Part III. Subsystem Control Facility (SCF)

14. Subsystem Control Facility (SCF) CommandsOverview of the Expand Subsystem SCF Interface 14-2

Expand Subsystem Objects 14-2

Object States 14-4

SCF Commands and Objects 14-5

Sensitive and Nonsensitive Commands 14-5

Wild-Card Support 14-6

Time Values 14-6

SCF and the WAN Subsystem 14-7

SCF and the SLSA Subsystem 14-8

ABORT Command 14-8

Considerations 14-8

Examples 14-9

ACTIVATE Command 14-9

Considerations 14-9

Example 14-9

ALTER Command 14-10

ALTER DEVICE Command 14-10


ALTER PATH Command 14-11


Examples 14-12

ALTER LINE Command 14-12


Examples 14-20

ALTER PROCESS Command 14-21

Example 14-23

Expand Configuration and Management Manual — 529522-013ix

Contents 14. Subsystem Control Facility (SCF) Commands

DELETE ENTRY Command 14-23


Examples 14-24

INFO Command 14-24

INFO PATH Command 14-25

OBEYFORM Option 14-30


INFO LINE Command 14-31

Direct-Connect and Satellite-Connect Line-Handler Processes 14-31

Expand-Over-IP Line-Handler Processes 14-36

Expand-Over-ATM Line-Handler Processes 14-41


Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes 14-46


INFO PROCESS Command 14-50

CONNECTS Option 14-57

LINESET Option 14-58

NETMAP Option 14-62


PATHSET Option 14-65

RPT Option 14-66

SUPERPATH Option 14-67

SYSTEMS Option 14-68

PRIMARY PROCESS Command 14-70


Examples 14-70

PROBE PROCESS Command 14-71

START Command 14-73


Examples 14-74

STATS Command 14-74

STATS PATH Command 14-74


Examples 14-80

STATS PATH NODE Command 14-81

Examples 14-85

STATS LINE Command 14-85

Expand-Over-IP Line-Handler Processes 14-85

Expand-Over-ATM Line-Handler Processes 14-87

Expand Configuration and Management Manual — 529522-013x

Contents 15. Tracing

Expand-Over-ServerNet, Expand-Over-X.25, and Expand-Over-SNA Line-Handler Processes 14-89

SWAN Concentrator Lines 14-91


Examples 14-95

STATS PROCESS Command 14-97

STATUS Command 14-101

STATUS PATH Command 14-101


Examples 14-103

STATUS LINE Command 14-103


Examples 14-110

STOP Command 14-111


Examples 14-111

TRACE Command 14-112


Examples 14-117

VERSION Command 14-117


Examples 14-118

VERSION PROCESS Command 14-118

15. TracingWhy Tracing Is Important 15-2

How to Use Tracing 15-2

Tracing $NCP 15-2

Tracing a Path or Single Line 15-2

Tracing a Line in a Multi-Line Path 15-3

Tracing Using SCF 15-3

PTrace Command Overview 15-5

FILTER Command 15-6

Considerations 15-6

Examples 15-7

FIND Command 15-7

Considerations 15-7

Examples 15-8

FROM Command 15-8

Expand Configuration and Management Manual — 529522-013xi

Contents 16. Expand Modifiers

Example 15-8

HEX Command 15-8

Example 15-9

LABEL Command 15-9

Example 15-9

NEXT Command 15-9

Example 15-10

OCTAL Command 15-10

Example 15-10

OUT Command 15-11

Example 15-11

RECORD Command 15-11

Examples 15-12

SELECT Command 15-12

Part IV. Reference Information

16. Expand ModifiersHow to Use This Section 16-1

Required Modifiers 16-1

Modifier Dictionary 16-4

AFTERMAXRETRIES_DOWN/ AFTERMAXRETRIES_PASSIVE 16-4

ASSOCIATEDEV $dev-name 16-4

ASSOCIATESUBDEV #n 16-5

ATMSEL n 16-5

CALLTYPE_PVC/CALLTYPE_SVC/CALLTYPE_ATMSAP 16-5

CLBIDLETIMER 16-6

CLOCKMODE_DCE/CLOCKMODE_DTE 16-6

CLOCKSPEED_600/CLOCKSPEED_1200 CLOCKSPEED_2400/CLOCKSPEED_4800 CLOCKSPEED_9600/CLOCKSPEED_19200 CLOCKSPEED_38400/CLOCKSPEED_56000 CLOCKSPEED_115200 16-6

COMPRESS_OFF/COMPRESS_ON 16-7

CONNECTTYPE_ACTIVEANDPASSIVE/ CONNECTTYPE_PASSIVE 16-7

DELAY n 16-8

DESTATMADDR n 16-8

DESTIPADDR n 16-9

Expand Configuration and Management Manual — 529522-013xii

Contents 16. Expand Modifiers

DESTIPPORT n 16-9

DOWNIFBADQUALITY ON/ DOWNIFBADQUALITY OFF 16-9

EXTMEMSIZE n 16-9

FLAGFILL_OFF/ FLAGFILL_ON 16-10

FRAMESIZE n 16-10

INTERFACE_RS232/INTERFACE_RS422 16-10

IPVER_IPV4/IPVER_IPV6 16-11

L2DISCARDONRESET_OFF/L2DISCARDONRESET_ON 16-11

L2RETRIES n 16-11

L2TIMEOUT n 16-12

L4CONGCTRL_OFF/L4CONGCTRL_ON 16-13

L4CWNDCLAMP n 16-13

L4EXTPACKETS_OFF/L4EXTPACKETS_ON 16-14

L4RETRIES n 16-15

L4SENDWINDOW n 16-15

L4TIMEOUT n 16-16

LIFNAME n 16-16

LINEPRIORITY n 16-17

LINETF n 16-17

MAXRECONNECTS n 16-17

NEXTSYS n 16-18

OSSPACE n 16-18

OSTIMEOUT n 16-18

PATHBLOCKBYTES n 16-19

PATHPACKETBYTES n 16-19

PATHTF n 16-20

PROGRAM n 16-20

PVCNAME n 16-21

QUALITYTHRESHOLD n 16-21

QUALITYTIMER n 16-21

RETRYPROBE n 16-21

RSIZE n 16-22

RXWINDOW n 16-22

SPEED n 16-23

SPEEDK n 16-23

SRCIPADDR n 16-25

SRCIPPORT n 16-25

STARTUP_OFF/STARTUP_ON 16-25

SUPERPATH_OFF/SUPERPATH_ON 16-25

Expand Configuration and Management Manual — 529522-013xiii

Contents 17. Subsystem Description

TIMERINACTIVITY n 16-26

TIMERPROBE n 16-26

TIMERRECONNECT n 16-27

TXWINDOW n 16-27

V6DESTIPADDR n 16-28

V6SRCIPADDR n 16-29

Profiles 16-29

Single-Line Expand Line-Handler Process Modifiers 16-29

Multi-Line Path Modifiers 16-32

17. Subsystem DescriptionExpand Subsystem Components 17-2

Expand Line-Handler Processes 17-2

Network Control Process ($NCP) 17-6

Expand Manager Process ($ZEXP) 17-7

Components Summary 17-8

Expand Subsystem and the OSI Reference Model 17-9

Expand Line-Handler Process Layer Functions 17-10

$NCP Layer Functions 17-12

Path Function of the Expand Subsystem 17-13

Protocol Packet Types 17-13

Packet Synchronization 17-16

Example of End-to-End Protocol Packet Exchanges 17-16

Layer 4 Send Window 17-21

Routing and Time Factors 17-22

Setting Time Factors 17-23

Negotiating Path Time Factors 17-24

Best-Path Route Selection 17-24

Network Routing Table (NRT) and Multiple Path Table (MPT) 17-25

Calculating Route Time Factors 17-27

Routing Algorithms 17-28

Multi-CPU Paths 17-31

Multi-CPU Routing Examples 17-34

Message Handling and Buffer Allocation 17-38

Outgoing Traffic Flow 17-38

Incoming Traffic Flow 17-42

Message Buffering 17-46

Global Variables 17-47

Stack 17-47

Expand Configuration and Management Manual — 529522-013xiv

Contents 17. Subsystem Description

Control Blocks 17-47

Line Buffer 17-47

Buffer Pool 17-47

Shared Memory Area for QIO 17-48

Expand-to-NAM Interface 17-49

Network Access Method (NAM) Processes 17-49

Connection Establishment 17-50

Sending and Receiving Data 17-52

Expand-to-IP Interface 17-53

NonStop TCP/IP Processes 17-53

Expand-over-IP Connection Establishment 17-54


Forwarding Expand-over-IP Packets to Other Expand Line-Handler Processes 17-56

Expand-to-ATM Interface 17-58

ATM Subsystem 17-58

Expand-over-ATM Connection Establishment 17-59


Forwarding Expand-over-ATM Packets to Other Expand Line-Handler Processes 17-62

Multipacket Frame Feature 17-63

Constructing Multipacket Frames 17-63

Path Initialization 17-65

Multipacket Frame Configuration 17-66

Multipacket Frame Considerations 17-66

Variable Packet Size Feature 17-67

Variable Packet Size Configuration 17-67

Variable Packet Size Considerations 17-67

Mixing Extended and Nonextended Packets 17-68

Considerations for Paths Using the Variable Packet Size Feature and the Multipacket Frame Feature 17-69

Congestion Control Feature 17-69

Congestion Control Configuration 17-71

Congestion Control Considerations 17-71

Multi-CPU Feature 17-72


Multi-CPU Configuration 17-72

Multi-CPU Considerations 17-73

Expand Configuration and Management Manual — 529522-013xv

Contents 18. Managing the Network

Part V. Management, Tuning, and Troubleshooting

18. Managing the NetworkAccessing Network Resources 18-1

Using TACL to Manage Remote Files 18-2

Using Disk-File Names 18-2

Changing Your Default Values 18-3

Gaining Access to Remote Nodes 18-4

Setting Up Network Security 18-7

Remote File Security 18-7

Establishing Global User IDs 18-7

Establishing Remote Passwords 18-8

Remote Process Security 18-9

Remote TACL Processes 18-10

Global Remote Passwords 18-10

Subnetwork Security 18-11

Remote Super ID User 18-11

Additional Security Techniques 18-12

Monitoring Network Activity 18-13

Displaying $NCP Information 18-13

Displaying Expand Line-Handler Process Information 18-15

Starting and Stopping Tracing 18-19

Reconfiguring the Network 18-20

Adding and Deleting Expand Line-Handler Processes 18-20

Adding and Deleting $NCP 18-20

Changing $NCP Modifiers 18-20

Changing Expand Line-Handler Process Modifiers 18-21

Changing Profiles 18-21

Adding Nodes to the Network 18-21

Removing Nodes From the Network 18-22

Changing System Names and Numbers 18-23

Controlling the Network 18-26

Starting and Stopping Expand Line-Handler Processes and $NCP 18-26

Stopping and Starting Lines and Paths 18-27

Switching Primary and Backup Processes 18-28

Rebalancing Multi-CPU Paths 18-28

Expand Configuration and Management Manual — 529522-013xvi

Contents 19. Tuning

19. TuningThe Role of Network Tuning 19-1

Tuning Goals 19-1

Performance Factors 19-2

How to Use the Performance Factors Table 19-2

Multipacket Frame Size 19-3

Variable Packet Size 19-5

Application Message Size 19-7

Packet Format 19-9

Congestion Control 19-9

Layer 2 Window Size 19-10

Processor Type 19-11

NAM Interface 19-12

Data Compression 19-12

Multi-Line Paths 19-13


Network Topology 19-20

Summary of Tuning Strategies 19-21

Measuring and Mapping an Expand Network 19-22

What the Utilities Show 19-22

Using Measure 19-23

Measuring Passthrough Traffic 19-28

Setting Measurement Intervals 19-28

Tuning Examples 19-28

Example 1: Changing Packet Size 19-28

Example 2: Reducing Passthrough Traffic 19-31

20. TroubleshootingUnderstanding Your Network 20-1

Collecting Network Information 20-1

EMS 20-1

SCF 20-1

Measure 20-2

ASAP 20-2

Identifying Network Problems 20-3

User Complaints 20-4

SCF Commands 20-4

Problem Check-List Summary 20-10

Resolving Specific Network Problems 20-11

Expand Configuration and Management Manual — 529522-013xvii

Contents A. SCF Error Messages

$NCP Problems 20-11

Expand Line-Handler Process Problems 20-12

SWAN Concentrator Problems 20-13

WAN Subsystem Problems 20-15

Expand-Over-X.25 Problems 20-18

Expand-Over-IP Problems 20-19

Expand-Over-ATM Problems 20-23

Multi-CPU Path Problems 20-28

Reporting Network Problems 20-29

Tracing 20-29

Resolving Common Network Problems 20-31

Slow Response Time 20-31

Network Congestion 20-33

Node Not Available 20-33

Adding Low-Speed Lines to a Multi-Line Path 20-36

Duplicate Node 20-36

A. SCF Error MessagesExpand Error 00001 A-1

Expand Error 00002 A-1




















Expand Configuration and Management Manual — 529522-013xviii

Contents B. Expand and WAN SCF Comparison

B. Expand and WAN SCF ComparisonCommand Comparison B-1

ALTER Command Comparison B-7

Modifier-to-Attribute Comparison B-7

Altering Timeout Periods B-8

Glossary

Index

ExamplesExample 1-1. SCF STATUS ADAPTER Command 1-7

Example 1-2. SCF INFO ADAPTER Command 1-8

Example 1-3. SCF STATUS PROCESS Command 1-9

Example 6-1. SCF STATUS $NCP Command 6-4

Example 7-1. SCF STATUS ADAPTER Command 7-6

Example 8-1. SCF LISTDEV TCPIP Command 8-9

Example 8-2. SCF INFO SUBNET Command 8-10

Example 8-3. SCF INFO SUBNET, DETAIL Command 8-12



Example 8-6. SCF INFO SUBNET $ZSAM0 8-16

Example 8-7. SCF STATUS PROCESS Command 8-17

Example 8-8. SCF STATUS MON Command 8-19

Example 8-9. SCF LISTOPENS MON Command 8-20

Example 8-10. \NodeB: Configure an Expand-over-TCP/IPv6 Line Using Configured-Tunnel 8-28

Example 8-11. Add an Expand Line to \NodeC 8-29

Example 8-12. \NodeC: Configure an Expand-over-NonStop TCP/IPv6 Line Using Configured-Tunnel 8-29

Example 8-13. Add an Expand Line to \NodeB 8-30

Example 8-14. TACL Macro \NodeB: Configure an Expand-over-CIP Line With a Tunnel 8-30

Example 8-15. Add an Expand Line to \NodeC 8-31

Example 8-16. \NodeC: Configure an Expand-over-CIP Line Using a Tunnel 8-31

Example 8-17. Add an Expand Line to \NodeB 8-32

Example 9-1. SCF INFO PVC Command 9-6

Example 9-2. ATM Subsystem SCF INFO LINE, DETAIL Command 9-7

Example 9-3. Expand Subsystem SCF INFO LINE, DETAIL Command for SVC 9-8

Expand Configuration and Management Manual — 529522-013xix

Contents Examples

Example 9-4. Expand Subsystem SCF INFO LINE, DETAIL Command for ATMSAP 9-10

Example 9-5. Altering the CALLTYPE Modifier and LIFNAME 9-10

Example 14-1. INFO PATH Command 14-25

Example 14-2. INFO PATH, DETAIL Command 14-26

Example 14-3. INFO PATH $LHPATH, OBEYFORM command 14-30

Example 14-4. INFO LINE Command, Direct- and Satellite-Connect Line-Handler Processes 14-31

Example 14-5. INFO LINE, DETAIL Command, Direct- and Satellite-Connect Line-Handler Processes 14-32

Example 14-6. INFO LINE Command, Expand-Over-IP Line-Handler Processes 14-36

Example 14-7. INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler Processes for IPv4 Lines 14-37

Example 14-8. INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler Processes for IPv6 Lines 14-38

Example 14-9. INFO LINE Command, Expand-Over-ATM Line-Handler Processes 14-41

Example 14-10. INFO LINE, DETAIL Command, Expand-Over-ATM Line-Handler Processes 14-42

Example 14-11. INFO LINE $<line-name>, OBEYFORM command for Expand over ATM line 14-45

Example 14-12. INFO LINE Command, Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes 14-46

Example 14-13. INFO LINE, DETAIL Command, Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes 14-47

Example 14-14. INFO PROCESS $NCP Command 14-53

Example 14-15. INFO PROCESS $NCP, DETAIL Command 14-54

Example 14-16. INFO PROCESS $NCP Command, CONNECTS Option 14-57

Example 14-17. INFO PROCESS $NCP Command, LINESET Option 14-60

Example 14-18. INFO PROCESS $NCP Command, NETMAP Option 14-62

Example 14-19. INFO PROCESS $NCP, OBEYFORM command 14-64

Example 14-20. INFO PROCESS $NCP Command, PATHSET Option 14-65

Example 14-21. INFO PROCESS $NCP Command, RPT Option 14-66

Example 14-22. INFO PROCESS $NCP Command, SUPERPATH Option 14-67

Example 14-23. INFO PROCESS $NCP Command, SYSTEMS Option 14-68

Example 14-24. PROBE PROCESS $NCP Command 14-72

Example 14-25. STATS PATH Command 14-75

Example 14-26. STATS PATH NODE Command 14-82

Example 14-27. STATS LINE Command, Expand-Over-IP Line-Handler Processes 14-85

Expand Configuration and Management Manual — 529522-013xx

Contents Figures

Example 14-28. STATS LINE Command, Expand-Over-ATM Line-Handler Processes 14-87

Example 14-29. STATS LINE Command, Expand-Over-ServerNet Line-Handler Processes 14-89

Example 14-30. STATS LINE Command, SWAN Concentrator Lines 14-91

Example 14-31. STATS PROCESS $NCP Command, NETFLOW Option 14-99

Example 14-32. STATS PROCESS $NCP Command, LOCALFLOW Option 14-100

Example 14-33. STATUS PATH Command 14-101

Example 14-34. STATUS PATH, DETAIL Command 14-102

Example 14-35. STATUS LINE Command 14-103

Example 14-36. STATUS LINE, DETAIL Command, Direct- and Satellite-Connect Line-Handler Processes 14-104

Example 14-37. STATUS LINE, DETAIL Command, LINE Object 14-106

Example 14-38. VERSION PROCESS Command 14-118

Example 19-1. SYSTEM Entity Display 19-23

Example 19-2. NETLINE Entity Display 19-24

Example 19-3. LINE Entity Display 19-25

Example 19-4. PROCESS Entity Display 19-26

Example 19-5. CPU Entity Display 19-26

Example 19-6. SCF PATH STATS Display 19-29

Example 19-7. Passthrough Traffic From Measure SYSTEM Counters on \JUICE 19-32

Example 19-8. Passthrough Traffic in a Network 19-33

Example 20-1. SCF LISTDEV Display 20-5

Example 20-2. SCF STATS Display 20-6

Example 20-3. SCF STATUS Display 20-6

Example 20-4. SCF INFO PROCESS $NCP, LINESET Display 20-7

Example 20-5. SCF INFO PROCESS $NCP, NETMAP Display 20-9

Example 20-6. SCF PROBE PROCESS, $NCP Display 20-10

Example 20-7. SCF STATUS LINE, DETAIL Command 20-19

Example 20-8. SCF STATS LINE Command (Expand-Over-IP) 20-21

Example 20-9. SCF INFO LINE, DETAIL Command (Expand-Over-IP) 20-22

Example 20-10. SCF STATUS LINE, DETAIL Command 20-23

Example 20-11. SCF STATS LINE Command (Expand-Over-ATM) 20-26

Example 20-12. SCF INFO LINE, DETAIL Command (SVC Connection) 20-26

Example 20-13. SCF PROBE Display 20-31

FiguresFigure 2-1. Single-Server Process Communications 2-3

Figure 2-2. Multi-Node Process Communications 2-4

Expand Configuration and Management Manual — 529522-013xxi

Contents Figures

Figure 3-1. Multi-Line Path With Eight Lines and Two SWAN Concentrators 3-8

Figure 3-2. Multi-Line Path With Eight Lines and Eight SWAN Concentrators 3-9

Figure 3-3. Multi-CPU Path With Three Paths 3-10

Figure 3-4. Common Network Topologies 3-13

Figure 3-5. Network Diagram 3-15

Figure 4-1. ServerNet Clusters Connected by ATM or IP Lines 4-5

Figure 4-2. ServerNet Clusters Connected by a Single ATM or IP Line (Not Recommended) 4-6

Figure 4-3. ServerNet Cluster Using Layered Topology With Connections to Nodes Outside the Cluster 4-7

Figure 7-1. Direct-Connect and Satellite-Connect Connectivity Components 7-2

Figure 7-2. Direct-Connect and Satellite-Connect Line-Handler Process Topology 7-4

Figure 8-1. Expand-Over-IP Connectivity Components with a LAN Adapter or CLIM 8-2

Figure 8-2. Expand-Over-IP Connectivity Components with ATM3SA 8-3

Figure 8-3. Expand-Over-IP Line-Handler Process Topology 8-7

Figure 9-1. Expand-Over-ATM Connectivity Components 9-2

Figure 9-2. Expand-Over-ATM Line-Handler Process Topology 9-4

Figure 9-3. Expand and ATMSAP 9-9

Figure 10-1. Expand-Over-X.25 Line-Handler Process Components 10-2

Figure 10-2. Expand-Over-X.25 Line-Handler Process Topology 10-5

Figure 11-1. Expand-Over-SNA Line-Handler Process Components 11-2

Figure 11-2. Expand-Over-SNA Line-Handler Process Topology 11-5

Figure 11-3. SNAX/APN Line Configuration Example 11-9

Figure 12-1. Expand-Over-ServerNet Connectivity Components 12-2

Figure 12-2. Expand-Over-ServerNet Topology 12-6

Figure 13-1. Logical Devices for a Multi-Line Path 13-1

Figure 13-2. Multi-Line Configuration Example 13-15

Figure 14-1. Expand Subsystem Object Hierarchy 14-2

Figure 15-1. Tracing Process Using SCF 15-4

Figure 17-1. Expand Network Environment 17-8

Figure 17-2. Expand Subsystem Protocol Layers 17-9

Figure 17-3. Normal Exchange 17-17

Figure 17-4. Lost Data 17-18

Figure 17-5. Lost Acknowledgment 17-19

Figure 17-6. Buffer Pool Failure 17-20

Figure 17-7. $NCP Exchange of Network Change Information 17-26

Figure 17-8. Sample Network With Time Factors 17-27

Figure 17-9. Routing Information With the MSH Algorithm 17-29

Expand Configuration and Management Manual — 529522-013xxii

Contents Tables

Figure 17-10. Routing Information With the SH Algorithm 17-30

Figure 17-11. Network Containing Normal Paths and Multi-CPU Paths 17-35

Figure 17-12. Flow of an Outgoing Local Message 17-39

Figure 17-13. Flow of Outgoing $NCP and Passthrough Traffic 17-41

Figure 17-14. Flow of Incoming Packets 17-43

Figure 17-15. Expand Line-Handler Process Data Space 17-46

Figure 17-16. Expand-Over-NAM Connection Establishment 17-50

Figure 17-17. Expand-Over-IP Packet Forwarding 17-57

Figure 17-18. Expand-Over-ATM Packet Forwarding 17-62

Figure 17-19. Multipacket Frame Feature Not Selected 17-64

Figure 17-20. Multipacket Frame Feature Selected 17-65

Figure 17-21. Mixing Extended and Nonextended Packets 17-68

Figure 17-22. Congestion Control Not Enabled 17-70

Figure 17-23. Congestion Control Not Supported 17-70

Figure 19-1. Throughput With and Without Multipacket Frames 19-4

Figure 19-2. Application Data Flow for Expand-Over-IP 19-7

Figure 19-3. CPU Matching 19-17

Figure 19-4. Pair Count Balancing for Neighbors and Non-Neighbors 19-18

Figure 19-5. Passthrough Traffic 19-20

Figure 19-6. Packet Size/Bandwidth Comparison 19-31

Figure 20-1. Network Problem Hierarchy 20-3

TablesTable i. Summary of Contents—Part I xxxiv

Table ii. Summary of Contents—Part II xxxiv

Table iii. Summary of Contents—Part III xxxv

Table iv. Summary of Contents—Part IV xxxv

Table v. Summary of Contents—Part V xxxvi

Table vi. Summary of Appendixes xxxvi

Table 1-1. Profiles for Single-Line Expand Line-Handler Processes 1-4

Table 1-2. Profiles for Line-Logical Devices 1-5

Table 1-3. SCF ADD DEVICE Command Worksheet 1-10

Table 1-4. SCF ADD DEVICE Syntax: Expand-Over-IP 1-11

Table 1-5. SCF ADD DEVICE Syntax: Expand-Over-ATM 1-13

Table 1-6. SCF ADD DEVICE Syntax: Expand-Over-X.25, Expand-Over-SNA, and Expand-Over-ServerNet 1-15

Table 1-7. ADD DEVICE Syntax: Path-Logical Device 1-16

Table 1-8. Subtypes for Line-Logical Devices 1-17

Table 2-1. Online Reconfiguration Tasks 2-10

Expand Configuration and Management Manual — 529522-013xxiii

Contents Tables

Table 5-1. Configuration Steps 5-2

Table 5-2. Expand Profile Templates 5-3

Table 7-1. PEXQSSWN and PEXQSSAT Modifiers 7-12

Table 8-1. PEXQSIP Modifiers for Expand-over-IP Lines 8-34

Table 9-1. PEXQSATM Modifiers for Expand-over-ATM Lines 9-19

Table 10-1. PEXQSNAM Modifiers for Expand-over-X.25 Lines 10-14

Table 11-1. PEXQSNAM Modifiers for Expand-over-SNA Lines 11-16

Table 12-1. Profile Products Needed for Compatibility With Other Expand Lines 12-4

Table 12-2. PEXPSSN Modifiers for Expand-over-ServerNet Lines 12-13

Table 13-1. Profiles for Line-Logical Devices 13-5

Table 13-2. Device Subtypes for Line-Logical Devices 13-9

Table 13-3. PEXPPATH Modifiers 13-17

Table 13-4. PEXQMSWN and PEXQMSAT Modifiers 13-18

Table 13-5. PEXQMNAM Modifiers 13-20

Table 13-6. PEXQMIP Modifiers 13-21

Table 13-7. PEXQMATM Modifiers 13-22

Table 14-1. Expand Commands and Object Types 14-5

Table 14-2. Sensitive and Nonsensitive Expand SCF Commands 14-6

Table 14-3. ALTER PATH Attributes and Corresponding Profile Modifiers 14-11

Table 14-4. ALTER LINE Attributes and Corresponding Profile Modifiers 14-14

Table 14-5. ALTER LINE Attributes 14-19

Table 14-6. ALTER PROCESS Attributes and Corresponding Profile Modifiers 14-21

Table 14-7. Messages and Corresponding Event Numbers 14-109

Table 14-8. $NCP Trace Records 14-114

Table 14-9. LINE Object Trace Records 14-115

Table 14-10. PATH Object Trace Records 14-115

Table 15-1. PTrace Commands Summary 15-5

Table 15-2. Number of Trace Lines Displayed 15-10

Table 15-3. SELECT Options for Expand 15-12

Table 16-1. Required Modifiers 16-1

Table 16-2. Time Factor and SPEEDK Conversions 16-24

Table 16-3. Single-Line Path Modifiers 16-29

Table 16-4. Modifiers for Line-Logical Devices 16-32

Table 18-1. Expand SCF Commands for $NCP Information 18-13

Table 18-2. WAN SCF Commands for $NCP Information 18-15

Table 18-3. Expand SCF Commands for Expand Line-Handler Processes 18-15

Table 18-4. Subtype Values for Single-Line Line-Handler Processes 18-16

Expand Configuration and Management Manual — 529522-013xxiv

Contents Tables

Table 18-5. Subtype Values for Multi-Line Paths (Path and Line Logical Devices) 18-16

Table 18-6. WAN SCF Commands for Expand Line-Handler Process Information 18-16

Table 18-7. Expand SCF Commands for Line Information 18-17

Table 18-8. Expand SCF Commands for Path Information 18-18

Table 18-9. Expand SCF Commands for Tracing 18-19

Table 18-10. Expand SCF Status Commands 18-22

Table 18-11. Expand SCF Control Commands 18-27

Table 18-12. Expand SCF Commands for Switching Processors 18-28

Table 19-1. Performance Factors 19-2

Table 19-2. Data-Per-Packet Percentages 19-9

Table 19-3. Summary of Tuning Strategies 19-21

Table 20-1. LISTDEV TYPE Identifiers 20-2

Table 20-2. Verifying Processes Using the SCF LISTDEV Command 20-4

Table 20-3. Identifying Problems With Expand Subsystem SCF Commands 20-5

Table 20-4. Common File-System Errors 20-7

Table 20-5. Network Problem Check List 20-10

Table 20-6. Identifying $NCP Problems With SCF Commands 20-11

Table 20-7. Expand Line-Handler Process Problem-Resolution Procedures 20-12

Table 20-8. SWAN Concentrator Problem-Resolution Check List 20-13

Table 20-9. WAN Subsystem Problem-Resolution Check List 20-15

Table 20-10. Expand-Over-X.25 Problem-Resolution Procedures 20-18

Table 20-11. Detailed States (Expand-Over-IP) 20-19

Table 20-12. Messages Displayed in the Detailed Info Field (Expand-Over-IP) 20-22

Table 20-13. Messages and Corresponding Event Numbers 20-23

Table 20-14. Detailed States (Expand-Over-ATM) 20-24

Table 20-15. Messages Displayed in the Detailed Info Field (Expand-Over-ATM) 20-27

Table 20-16. Multi-CPU Path Problem Resolution Procedures 20-28

Table 20-17. SCF Commands to Locate a “Downed” Path 20-34

Table B-1. Expand and WAN SCF Command Comparison B-1

Expand Configuration and Management Manual — 529522-013xxv

Contents Tables

Expand Configuration and Management Manual — 529522-013xxvi

What’s New in This Manual

Manual InformationExpand Configuration and Management Manual

Abstract

This manual describes how to plan, configure, manage, and troubleshoot the Expand subsystem on an HP Integrity NonStop™ BladeSystem and HP Integrity NonStop NS-series server. The Expand subsystem can 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 server. This manual includes detailed descriptions of SCF commands and modifiers used with the Expand subsystem.

Product Version

Expand H01

Supported Release Version Updates (RVUs)

This manual supports J06.10 and all subsequent J-series RVUs and H06.21 and all subsequent H-series RVUs, until otherwise indicated by its replacement publications.

Document History

New and Changed Information

Changes to the 529522-013 manual:

• Updated Example 14-25 with new fields and values.

• Added Cur Recv Queue Messages and Max Recv Queue Messages attributes and descriptions to the STATS PATH command example.

• Updated Example 14-26 with new fields and values.

Part Number Published

529522-013 February 2014

Part Number Product Version Published

529522-008 Expand H01 June 2010

529522-009 Expand H01 August 2010

529522-010 Expand H01 August 2012


529522-012 Expand H01 April 2013


Expand Configuration and Management Manual — 529522-013xxvii

What’s New in This Manual Changes to the 529522-012 manual:

• Added the following attributes and descriptions to the STATS PATH NODE command example.

° Average RTT

° RTT Std Dev

° Min RTT

° Max RTT

• Added a consideration the ALTER LINE Command on page 14-12.

• Appended the Delay attribute with * in the following examples as it is an alterable attribute:

• Example 14-7 on page 14-37



Changes to the 529522-012 manual:

• Updated the attribute OStimeout on page 14-26.

Changes to the H06.26/J06.15 manual:

• Added the modifier REBALTHRESHOLD n on page 6-6.

• Updated the syntax for the ALTER PROCESS Command on page 14-21.

• Updated the example INFO PROCESS $NCP, DETAIL Command on page 14-54.

• Added the option RebalThreshold on page 14-57.

• Updated the example INFO PROCESS $NCP, OBEYFORM command on page 14-64.

• Updated the section Load Balancing on page 17-32.

• Updated the section Load Balancing on page 19-16


• Updated the section Task 1: Configure and Start $NCP on page 1-2.

• Updated the section Step 2: Create $NCP on page 6-2.

• Updated the section Step 3: Start $NCP on page 6-4.

• Updated the following with description of L4CWNDCLAMP modifier:

° Profile Modifiers on page 7-12.

° Modifiers for Special Features on page 8-33.

Expand Configuration and Management Manual — 529522-013xxviii

What’s New in This Manual Changes to the H06.21/J06.10 manual:




° Profile Modifiers on page 12-13.

° Path-Logical Device Modifiers on page 13-16.

• Updated the following tables with description of L4CWNDCLAMP modifier:

° PEXQSSWN and PEXQSSAT Modifiers on page 7-12.

° PEXQSIP Modifiers for Expand-over-IP Lines on page 8-34.

° PEXQSATM Modifiers for Expand-over-ATM Lines on page 9-19.

° PEXQSNAM Modifiers on page 10-14.

° PEXQSNAM Modifiers for Expand-over-SNA Lines on page 11-16.

° Single-Line Path Modifiers on page 16-29.

• Added the L4CWNDCLAMP modifier option to the ALTER PATH Command on page 14-11.

• Added the L4CWNDCLAMP modifier option to the INFO PATH Command on page 14-25.

• Added the option L4CWNDCLAMP on page 14-28.

• Added the L4CWNDCLAMP modifier option to the example, INFO PATH $LHPATH, OBEYFORM command on page 14-30

• Added the modifer L4CWNDCLAMP n on page 16-13 to the section, Modifier Dictionary.

• Added the L4CWNDCLAMP modifier option to the Multi-Line Path Modifiers on page 16-32.

• Updated the section, Congestion Control Configuration on page 17-71.


• Updated instances of "16 multi-CPU paths in a system" to "32 multi-CPU paths in a system" in the following sections:

° SUPERPATH_OFF/SUPERPATH_ON on page 16-26

° Multi-CPU Considerations on page 17-73

Changes to the J06.04 Manual (529522-008 Edition)

• Updated Step 3: View the current system name and number on page 18-24.

Expand Configuration and Management Manual — 529522-013xxix

What’s New in This Manual Changes to the J06.04 Manual (529522-007 Edition)

• Added Local Area Network (LAN) Driver and Interrupt Handlers (DIHs) on page 10-4 for customer feedback.

• Corrected minor typographical errors throughout.

Changes to the J06.04 Manual (529522-007 Edition)

• Added the term, NonStop BladeSystems, in About This Manual on page xxxiii.

• Updated the description of Cluster I/O Protocols (CIP) Configuration and Management Manual on page xxxviii.

• References to Release Version Updates (RVUs) throughout this manual have been updated to include references to J-series RVUs, where appropriate.

• Added the following terms in the Abbreviations list:

° CIP.

° CLIM.

° $$ZCIP.

• Added the subsystem name, CIP in Expand-Over-IP Line-Handler Process on page 1-10.

• Updated the tcpip_process parameter in Table 1-4 on page 1-11.

• Added the cipsam_process parameter in Table 1-4 on page 1-12.

• Updated information about Internet Protocol (IP) Networks on page 3-5.

• Updated the hardware and software components in Required Hardware and Software on page 8-2.

• Added CIP Process on page 8-4.

• Updated the description of Redundancy in Ethernet Adapters on page 8-4.

• Added a note on CIP subsystem in Local Area Network (LAN) Driver and Interrupt Handlers (DIHs) on page 8-5.

• Added the description of CLIM in LAN or ATM Adapters or the CLIM on page 8-6.

• Added the following configuration steps for CIP subsystem:

° Step 1 (C): Select a Process and SUBNET for CIP Use

° Step 2 (C): Identify an available UDP Port Number for CIP Use

• Updated the description of the following syntax terms of the ADD DEVICE command:

° CPU cpunumber

° ALTCPU altcpunumber

Expand Configuration and Management Manual — 529522-013xxx

What’s New in This Manual Changes to the H06.08 Manual

° ASSOCIATEDEV tcpip_process

° {IPVER_IPV4 | IPVER_IPV6}

° SRCIPADDR src_ipaddr

° SRCIPPORT src_ipport

° DESTIPADDR dest_ipaddr

° DESTIPPORT dest_ipport

° V6SRCIPADDR v6srcip-address

° V6DESTIPADDR v6destip-address

• Added examples to describe how to add a configured tunnel for an Expand Line for CIP on page 8-30.

• Updated the command name in Load Balancing on page 19-16.

• Added the following terms in Glossary:

° $ZZCIP

° $ ZZTCP

Changes to the H06.08 Manual

• Added the OBEYFORM option under:

° INFO Command on page 14-24

° INFO PATH Command on page 14-30

° INFO LINE Command on page 14-45

° INFO PROCESS Command on page 14-64

• Added the modifier, CLBIDLETIMER on page 16-6.

• Updated the default value for the modifiers, EXTMEMSIZE n on page 16-9, L4RETRIES n on page 16-15, QUALITYTHRESHOLD n on page 16-21, and TIMERRECONNECT n on page 16-27.

Changes to the H06.06 Manual

These topics have new references to documentation:

• Subsystem Control Facility (SCF) Commands on page 14-1

• Managing the Network on page 18-1

These topics have been updated with this note:

Note. The Integrity NonStop NS1000 server does not support ServerNet clusters.

Expand Configuration and Management Manual — 529522-013xxxi

What’s New in This Manual Changes to the H06.06 Manual

• Configuration Quick Start on page 1-1

• Assumptions on page 1-1

• ServerNet Clusters on page 2-6

• ServerNet Connections on page 3-6

• Designing the Network Topology on page 3-12

• Planning for ServerNet Clusters on page 4-1

• ServerNet Clusters Coexisting With ATM or IP Networks on page 4-3

• ServerNet Clusters Connected By ATM or IP Lines on page 4-4

• ServerNet Clusters Connected By a Single ATM or IP Line (Not Recommended) on page 4-5

• ServerNet Clusters Using Layered Topology With Connections to Nodes Outside the Cluster on page 4-6

• Configuring Expand-Over-ServerNet Lines on page 12-1

• Required Hardware and Software on page 12-2

• External System Area Network Manager (SANMAN) on page 12-3

• Profile Products on page 12-4

• ServerNet Cluster Monitor Process ($ZZSCL) on page 12-4

• ServerNet Cluster Product on page 12-5

• Topology Considerations on page 12-6

• Configuring a ServerNet Node on page 12-7

• Expand-Over-ServerNet Line-Handler Process on page 17-5

• NonStop TCP/IP Process on page 7-3

• SLSA Subsystem on page 9-3

• Local Area Network (LAN) Driver and Interrupt Handlers (DIHs) on page 10-4

Expand Configuration and Management Manual — 529522-013xxxii

About This ManualThe Expand Configuration and Management Manual describes how to plan, configure, and manage the Expand subsystem on an HP Integrity NonStop™ NS-series server and NonStop BladeSystems.

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 these 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, 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 ManualThis manual is written for anyone who is responsible for configuring, managing, or maintaining an Expand network. Application programmers who write network applications might find this manual useful.

It is assumed that you are familiar with the HP NonStop™ operating system, basic data-communications concepts. You should be familiar with the Cluster I/O Protocols (CIP) subsystem if you are using it.

How This Manual Is OrganizedThis manual consists of five main parts, two appendices, and a glossary. The Glossary contains technical terms and abbreviations used throughout the text.

Expand Configuration and Management Manual—529522-013xxxiii

About This Manual Part I Contents

Part I Contents

Part I, Getting Started, consists of Sections 1 through 4. Table i summarizes the contents of Part I.

Part II Contents

Part II, Configuring the Expand Subsystem, consists of Sections 5 through 13. These sections explain how to configure the various types of Expand line-handler processes. Table ii summarizes the contents of Part II.

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 line-handler 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.

Table ii. Summary of Contents—Part II


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 Direct-Connect and Satellite-Connect Lines

Explains how to configure and start single-line satellite-connect and direct-connect line-handler processes.

8 Configuring Expand-Over-IP Lines

Explains how to configure and start single-line Expand-over-IP line-handler processes. Includes information on NonStop TCP/IP, NonStop TCP/IPv6, and CIP.

9 Configuring Expand-Over-ATM Lines

Explains how to configure and start single-line Expand-over-ATM line-handler processes.

10 Configuring Expand-Over-X.25 Lines

Explains how to configure and start single-line Expand-over-X.25 line-handler processes.

Expand Configuration and Management Manual—529522-013xxxiv

About This Manual Part III Contents

Part III Contents

Part III, Subsystem Control Facility (SCF), consists of Sections 14 and 15. Table iii summarizes the contents of Part III.

Part IV Contents

Part IV, Reference Information, consists of Sections 16 and 17. Table iv summarizes the contents of Part IV.

11 Configuring Expand-Over-SNA Lines

Explains how to configure and start single-line Expand-over-SNA line-handler processes.

12 Configuring Expand-Over-ServerNet Lines

Explains how to configure Expand-over-ServerNet line-handler processes.

13 Configuring Multi-Line Paths

Explains how to configure and start multi-line paths.

Table iii. Summary of Contents—Part III


14 Subsystem Control Facility (SCF) Commands

Describes the Subsystem Control Facility (SCF) interface to the Expand subsystem and provides SCF command syntax.

15 Tracing Describes the tracing process when the SCF TRACE command is used with commands available in the PTrace facility.

Table iv. Summary of Contents—Part IV


16 Expand Modifiers Describes the modifiers that are related to the configuration of Expand line-handler processes. Modifiers are listed in alphabetical order.

17 Subsystem Description Provides a high-level technical description of the architecture and dynamics of the Expand subsystem.

Table ii. Summary of Contents—Part II

Section Title Contents (continued)

Expand Configuration and Management Manual—529522-013xxxv

About This Manual Part V Contents

Part V Contents

Part V, Management, Tuning, and Troubleshooting, consists of Sections 18 through 20. Table v summarizes the contents of Part V.

Appendixes

Table vi describes the appendixes in this manual.

Table v. Summary of Contents—Part V


18 Managing the Network This section explains how to access network resources, set up network security, and monitor, reconfigure, and control an Expand network.

19 Tuning This section provides guidelines for improving network performance and describes the tools available for measuring performance.

20 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.

Table vi. Summary of Appendixes


16 SCF Error Messages Describes the messages issued by the Expand SCF subsystem.

17 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—529522-013xxxvi

About This Manual Related Documentation

Related DocumentationYou might need a guided procedure or related manuals when configuring and managing an Expand network:

Guided Procedure for Configuring a ServerNet Node

To prepare an Integrity NonStop NS-series server to become a node in a ServerNet cluster, see the guided procedure online help for configuring a ServerNet node, which:

• Creates a ServerNet cluster for the first time

• Adds a node to an already configured ServerNet cluster

Manuals

• 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 the NonStop 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 Server Manual

Availability Statistics and Performance (ASAP) is an availability, state, and performance statistics collection infrastructure for the NonStop 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 an Integrity NonStop NS-series server. It includes detailed descriptions of the Subsystem Control Facility (SCF) commands used with the ATM subsystem.

Expand Configuration and Management Manual—529522-013xxxvii

About This Manual Manuals

• Cluster I/O Protocols (CIP) Configuration and Management Manual

This manual provides overview about the HP NonStop Cluster I/O Protocols (CIP) subsystem and the procedures for configuring, managing, and migrating to CIP.

• 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.

• 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.

• 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/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/IPv6 Migration Manual

This manual describes 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.

Expand Configuration and Management Manual—529522-013xxxviii

About This Manual Notation Conventions

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.

General Syntax Notation

This list summarizes the notation conventions for syntax presentation in this manual.

UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words. Type 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. Type 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 can 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

Expand Configuration and Management Manual—529522-013xxxix

About This Manual General Syntax Notation

{ } 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 can 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 }

| 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 [ , 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 typed 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 type 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 this example, no spaces are 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

Expand Configuration and Management Manual—529522-013xl

About This Manual Notation for Messages

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 / ] LINE

[ , attribute-spec ]…

Notation for Messages

This list summarizes the notation conventions for the presentation of displayed messages in this manual.

Bold Text. Bold text in an example indicates user input typed 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 can 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 can be arranged

Expand Configuration and Management Manual—529522-013xli

About This Manual Notation for Subnet

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 }

% 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

This list summarizes the notation conventions for SUBNET and subnet used in this manual.

UPPERCASE LETTERS. Uppercase letters indicate the NonStop 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 manual and its preceding version. 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 COBOL 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—529522-013xlii

About This Manual Abbreviations

AbbreviationsThis list defines abbreviations and acronyms used in this guide. Both industry-standard 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

CIP. Cluster I/O Protocols

CLIM. CLuster I/O Module

CLIP. Communications Line Interface Processor

ConMgr. Concentrator Manager Process

DLC. Data Link Control

DSM. Distributed Systems Management

DV. Distance Vector

ETF. Effective Time Factor

EMS. Event Management Service

FCSA. Fibre Channel ServerNet Adapter

FTP. File Transfer Protocol

G4SA. Gigabit Ethernet 4-port ServerNet Adapter

HC. Hop Count

HDLC. High-Level Data Link Control

IEEE. Institute of Electrical and Electronics Engineers

IOAM. Input/Output Adapter Module

IOP. Input-Output Process

IP. Internet Protocol

Expand Configuration and Management Manual—529522-013xliii

About This Manual Abbreviations

LAN. Local Area Network

LNP. Logical Network Partitioning

LU. Logical Unit

MPT. Multiple Path Table

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

SWAN. ServerNet Wide Area Network

TACL. HP Tandem Advanced Command Language

TCP/IP. Transmission Control Protocol/Internet Protocol

Expand Configuration and Management Manual—529522-013xliv

About This Manual HP Encourages Your Comments

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

$$ZCIP. Cluster I/O Protocols subsystem

$ZEXP. Expand Manager Process name

$ZNET. Subsystem Control Point process name

$ZNUP. Network Utility Process name

$ZPM. Persistence Manager 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

HP Encourages Your CommentsHP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to [email protected].

Include the document title, part number, and any comment, error found, or suggestion for improvement you have concerning this document.

Expand Configuration and Management Manual—529522-013xlv

About This Manual HP Encourages Your Comments

Expand Configuration and Management Manual—529522-013xlvi


Part I consists of these 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 — 529522-013

1 Configuration Quick Start

This section provides the basic information to 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, see Part II, Configuring the Expand Subsystem.

Task SummaryConfiguring and starting an Expand line-handler process involves these tasks:

• Task 1: Configure and Start $NCP on page 1-2

• Task 2: Start the Expand Manager Process on page 1-3

• 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-18

AssumptionsAt the beginning of this procedure, the Integrity NonStop NS-series server is assumed to be in this state:

• The default software configuration provided by HP manufacturing is running.

• The initial OSM configuration is complete.

• The ServerNet LAN Systems Access (SLSA) subsystem has been configured and started, and a LAN adapter 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 — 529522-0131 - 1

Configuration Quick Start Task 1: Configure and Start $NCP

Task 1: Configure and Start $NCPThe network control process ($NCP) is responsible for initiating and terminating server-to-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 these steps:

1. Log on to the Integrity NonStop NS-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 2, ALTCPU 3, TYPE (62,6), RSIZE 1

5. Start the network control process

-> START DEVICE $ZZWAN.#NCP

Where to Find More Information About This Task

Section 6, Configuring the Network Control Process

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.


Configuration Quick Start Task 2: Start the Expand Manager Process

Task 2: Start the Expand Manager Process1. The Expand subsystem requires that the Expand manager process ($ZEXP) be

running during network operation. To start the Expand manager process, enter this 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.

2. You can also start the Expand manager process at system startup by including this 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:

-> START PROCESS $ZZKRN.#ZEXP

3. To verify that the process has started successfully, enter this TACL command:

> STATUS $ZEXP


• 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 an Integrity NonStop system for the first time, for more information on how to modify and save modifications to a configuration file, see the SCF Reference Manual for H-Series RVUs.


Configuration Quick Start Task 3: Add the Expand Line-Handler Profile(s)

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 these steps:

1. If you want add a single-line Expand line-handler process, perform these 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.

2. If you want to add a multi-line path, perform these 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

Note. To add an Expand line-handler process that is part of a multi-CPU path, perform either Step 1 or Step 2 as described below.

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


Configuration Quick Start Where to Find More Information About This Task

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:

These 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 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.


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 Multi-Line Paths

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


Configuration Quick Start Task 4: Add the Expand Line-Handler Process

Task 4: Add the Expand Line-Handler ProcessThe 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. These 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

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, see Creating a Multi-Line Path on page 1-15.

Satellite-Connect and Direct-Connect Line-Handler Processes

To create a single-line satellite-connect or direct-connect line-handler process, perform these 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 on page 1-7 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.

Note. How to configure a single-line Expand line-handler process to be part of a multi-CPU path is described in Step 6.


Configuration Quick Start Creating a Single-Line Expand Line-Handler Process

2. Using the information obtained from the SCF STATUS ADAPTER command, record the following information in the SCF ADD DEVICE COMMAND WORKSHEET (see Table 1-3 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.

Example 1-1. SCF STATUS ADAPTER Command

WAN Manager STATUS ADAPTER for ADAPTER \NODEA.$ZZWAN.#S01 State........... STARTED 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 : $X25A Line............ 1 : FREE WAN Manager STATUS PATH for PATH \NODEA.$ZZWAN.#S01.1.A State :......... STARTED MEDIA TYPE...... ETHERNET MEDIA ADDRESS... %H000000000000



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 TCP6SAM processes for 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.

4. Using the names of the preferred and alternate NonStop TCP/IP 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 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 on page 1-9. The processor numbers are shown in boldface type.

Example 1-2. SCF INFO ADAPTER Command

WAN Manager Detailed Info Adapter \NODEA.$ZZWAN.#S01

*TrackId........... XR4T7D *TCPIP Name....... $ZB01C *ALTTCPIP Name..... $ZB018 Concentrator Type. SYNC KERNELCODE......... $SYSTEM.CSS00.C7953P00 *SNMPCODE.......... $SYSTEM.CSS00.C7849P00 *HOSTIP Address.... 172.016.035.117 ALTHOSTIP Address.. 172.016.045.119 GATEWAYIP Addr..... 000.000.000.000 ALTGATEWAYIP Addr.. 000.000.000.000 SUBNETMASK......... %HFFFFFF00 ALTSUBNETMASK...... %HFFFFFF00



5. Using the information obtained from the SCF STATUS PROCESS commands, record the processor numbers for the preferred and alternate NonStop TCP/IP or TCP6SAM processes in the cpunum and altcpunum fields of SCF ADD DEVICE Command Worksheet (see Table 1-3 on page 1-10), 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 (see Table 1-3 on page 1-10).

-> 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

Example 1-3. SCF STATUS PROCESS Command

-> STATUS PROCESS $ZB018

TCPIP Status process \NODEA.$ZB018

Status: Started PPID............. ( 0,319) BPID................ ( 1,292)

Proto Status Laddr Lport Faddr Fport SendQ RecvQ TCP LISTEN 0.0.0.0 ftp 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 finger 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 echo 0.0.0.0 * 0 0 -> STATUS PROCESS $ZB01C TCPIP Status process \NODEA.$ZB01C Status: Started PPID............. ( 1,303) BPID................ ( 0,328) Proto Status Laddr Lport Faddr Fport SendQ RecvQ TCP LISTEN 0.0.0.0 ftp 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 finger 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 echo 0.0.0.0 * 0 0

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-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 CIPSAM process for Cluster I/O Protocols (CIP), 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.

The procedure to configure NonStop TCP/IP processes is not described here. For more information, see Section 8, Configuring Expand-Over-IP Lines.

To create an Expand-over-IP line-handler process, perform this 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

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 Line-Handler 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.

Note. To use CIP for IP communications, add the Expand-over-IP line-handler device in the same way as done in Select a CIPSAM Process for your NonStop TCP/IP process. The CIP also supports IPv6 communications.



If you want to use IPv6 communications, add the device as:

-> 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 or cipsam_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


name The name of the profile you created in Task 3: Add the Expand Line-Handler 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 TCP/IP process you want to associate with the Expand-over-IP line-handler process. For NonStop TCP/IP, the tcpip_process must be configured in the same processor pair as the Expand-over-IP line-handler process. For NonStop TCP/IPv6 and CIP, the tcpip_process can be configured in any processor only if the TCP/IP monitor process is running on the processor where the Expand-line-handler process is configured.

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, 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 called logical network partitioning (LNP) that affects configuration. For more information on this feature, see Internet Protocol (IP) Networks on page 3-4.

* Supported only on systems running J06.04 and later J-series RVUs.



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 this step:

cipsam_process* The name of the CIP transport-service provider process you want to associate with the Expand-over-IP line-handler process. The CIPSAM process does not need to be configured in the same processor pair as the Expand-over-IP line-handler process. In CIP, the monitor process ($ZZCIP.#ZCMn, where n is the processor number) is configured in all processors by default. Therefore, additional considerations are not required for ensuring its operation in the Expand-over-IP line-handler process pair. If you use CIP for INET (IPv4) operations, the additional parameters for IPv6, IPVER_IPV6, V6SRCIPADDR, and V6DESTIPADDR are not needed. However, the DESTIPADDR parameter is required for INET operations. CIP has the ability to restrict data communications to a particular CLIM and this might affect Expand configuration. For more information on this feature, see Internet Protocol (IP) Networks on page 3-4.

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) Expand-over-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.

Table 1-4. SCF ADD DEVICE Syntax: Expand-Over-IP (page 2 of 2)


* Supported only on systems running J06.04 and later J-series RVUs.



1. Add the Expand-over-ATM line-handler process as a device to the WAN subsystem

Use this 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 this 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 this 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)






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, null-terminated, and case-sensitive. This modifier is only applicable to Expand-over-ATM line-handler processes that use ATMSAP connections though the SLSA subsystem.



Expand-Over-X.25, Expand-Over-SNA and Expand-Over-ServerNet Line-Handler Processes

Expand-over-X.25, Expand-over-SNA, and Expand-over-ServerNet line-handler processes require the services of these 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.

To create an Expand-over-X.25, Expand-over-SNA, or Expand-over-ServerNet line-handler process, perform this step:

1. Add the Expand-over-SNA, Expand-over-X.25, or Expand-over-ServerNet 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,&

pvc_name The name of the permanent virtual circuit (PVC) used by the Expand-over-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 line-handler 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.


Table 1-5. SCF ADD DEVICE Syntax: Expand-Over-ATM (page 2 of 2)



Configuration Quick Start Creating a Multi-Line Path

TYPE (63,subtype), RSIZE 0, PATHTF 3, ASSOCIATEDEV process, & ASSOCIATESUBDEV #subdevice, NEXTSYS sysnum

Creating a Multi-Line Path

This section describes how to configure a multi-line path.

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-over-ServerNet 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, and Expand-Over-ServerNet




cpunum The primary processor number.

altcpu The alternate processor number.

subtype The subtype. The subtype is 0 for Expand-over-X.25 and Expand-over-SNA line-handler processes; it is 4 for Expand-over-ServerNet line-handler processes.

process • 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.

subdevice • 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.



Configuration Quick Start Creating 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


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.



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.


Configuration Quick Start Where to Find More Information About This Task

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 these exceptions:

• Use the TYPE modifier values as shown in Table 1-8.

• Omit the NEXTSYS modifier; it was specified when you configured the path-logical device.

• Include the MULTI modifier as:

MULTI $path_name

where path_name is the name of the path-logical device you created in Step 1.

These rules apply when creating line-logical devices:


• The path-logical device and all the line-logical devices with which it is associated must be configured in the same processor pair.

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


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

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


Configuration Quick Start Task 5: Start the Expand Line-Handler Process

Section 12, Configuring Expand-Over-ServerNet Lines Section 13, Configuring Multi-Line Paths

Task 5: Start the Expand Line-Handler ProcessStart 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 path-logical device.

Establishing a ConnectionTo establish a connection between two Integrity NonStop NS-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.

For more information, see the System Generation Manual for Expand or the Dynamic System Configuration (DSC) Manual in the D-series documentation.

After 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 this 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 this 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 this command:

-> START LINE $line_name

where line_name is the name of a logical device.


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 these 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-8• Online Expansion and Reconfiguration on page 2-10• Network Security on page 2-11

Network TransparencyTo 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 this 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 this 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 Overview Programmatic Access

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 Operating System

The Expand subsystem is an extension of the HP NonStop operating system. You can use the same methods for remote and local file access because the NonStop operating system 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.

The upper size limit of 60K bytes has these limitations.

• The 60K byte messages can 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 operating system’s file system limit of 56K bytes has not been increased.


Expand Overview Expand Subsystem and the NonStop Operating System

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

VST037.vsd

Y-Fabric

X-Fabric

ServerNetAdapter

ServerNetAdapter Disks

UserProcess

DiskProcess

MessageSystem

MessageSystem

Processor 0 Processor 1


Expand Overview Expand Subsystem and the NonStop Operating System

Multi-Node Process Communications

Figure 2-2 illustrates the same file-system request as Figure 2-1 on page 2-3, except that the disk process resides on another node in the network rather than on another processor in the same server.

Multi-node process communications is the same as single-server process communications, with these 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.

Figure 2-2. Multi-Node Process Communications

VST038.vsd

Expand Link

UserProcess

MessageSystem

ExpandLine-Handler

Process

MessageSystem

SWAN

SWAN

X-Fabric

Y-Fabric


MessageSystem

MessageSystem

DiskProcess

ExpandLine-Handler

Process

SWAN

SWAN

X-Fabric

Y-Fabric


Node \A Node \B

LANAdapter

LANAdapter

LANAdapter

LANAdapter


Expand Overview Multiple Communications Environments

Multiple Communications EnvironmentsNodes 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

• 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.

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.

Note. There is no automatic dialing function within the Expand subsystem for dial-up lines.


Expand Overview Systems Network Architecture (SNA) Networks

Systems Network Architecture (SNA) Networks

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 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.

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 one kilometer) between the cluster switches and their connected nodes.

For more topology information, see Section 4, Planning for ServerNet Clusters.


Note. The Integrity NonStop NS-series server cannot participate in more than one ServerNet cluster.


Expand Overview Distributed Control

Distributed ControlThe 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 these 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 RoutingThe 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:

• Passthrough Routing • Best-Path Routing • Priority Routing

For more information on adjusting settings so that routing is optimal, see Time Factors and Pathchange Messages on page 17-24.

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 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 17, Subsystem Description.


Expand Overview Priority Routing

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 OperationUsing 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 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 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.

Network ManagementNetwork 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) on page 2-9• Event Management Service (EMS) on page 2-9• Availability Statistics and Performance (ASAP) on page 2-9• Measure on page 2-9 • OSM Interface on page 2-9


Expand Overview Subsystem Control Facility (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 14, 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 on ASAP, see these manuals: ASAP Client Manual, ASAP Server Manual, ASAP Extension Manual, and ASAP Migration Guide for NSX and OMF Users.

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.

OSM Interface

The HP Open System Management (OSM) product is the system management tool for Integrity NonStop NS-series systems. OSM offers a browser-based interface that provides scalability and high performance. OSM is required for support of Expand functionality. For more information on OSM, see the OSM User’s Guide.

Note. For more information on managing Expand using SCF, see Part III of this manual, Subsystem Control Facility (SCF).


Expand Overview Online Expansion and Reconfiguration

Online Expansion and ReconfigurationYou 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.

The SCF interface to the Expand subsystem is described in Section 14, Subsystem Control Facility (SCF) Commands. The SCF interface to the WAN subsystem is described in the WAN Subsystem Configuration and Management Manual.

Table 2-1. Online Reconfiguration Tasks

TaskSCF 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

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.


Expand Overview Network Security

Network SecurityThe 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.

Before you can access a file on a remote server, you must have the proper security in addition to 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 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.

Note. Setting up remote passwords is explained in the Guardian User’s Guide.


Expand Overview Enhanced Security Techniques


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-11• Designing the Network Topology on page 3-12 • Creating a Network Diagram on page 3-15

Selecting Line ProtocolsThe 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.

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.


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.

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; DATEX-P 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:

• Low cost. The cost of X.25 connections can be less than dedicated lines, depending on traffic volume. Cost can 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.

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.


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.

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.

Note. Accurately estimating workloads is essential to predicting cost and performance of X.25 links in Expand networks.


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.

Expand can use NonStop TCP/IPv6 for IP version 6 communications. You can run NonStop TCP/IP and NonStop TCP/IPv6 at the same time.

NonStop TCP/IPv6 has three operating modes: INET, INET6, and DUAL. In the INET mode, only IP version 4 communications are supported. In the DUAL mode, both IPv4 and IPv6 communications are supported. In the INET6 mode, only IPv6 communications are supported.

One of the differences between the conventional NonStop TCP/IP subsystem and NonStop TCP/IPv6 for Expand is that there are no matching-processor configuration requirements for the TCP6SAM processes and the Expand line-handler processes. Another difference is that when you select a 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.

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.


Planning a Network Design Asynchronous Transfer Mode (ATM) Networks

When you are planning your Expand-over-IP environment, you can use LNP to control over which network interfaces (IP addresses) the Expand line-handler processes run. For examples of working with logical network partitioning, see Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use on page 8-11.

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 or TCP6SAM, which identifies the process as a NonStop TCP/IPv6 process. NonStop TCP/IP can coexist on the system with NonStop TCP/IPv6.

For more information on LNP and about NonStop TCP/IPv6, see the TCP/IPv6 Configuration and Management Manual and the TCP/IPv6 Migration Manual. For more information on NonStop TCP/IP, see the TCP/IP Configuration and Management Manual.

The CIP subsystem does not require a matching-processor configuration for the CIPSAM and Expand line-handler processes. Like NonStop TCP/IPv6, CIP transport service provider processes (CIPSAM) provide access to all configured Internet interfaces. Also, CIP can be configured to restrict its communications to a single CLIM. Unlike NonStop TCP/IPv6, CIP cannot be restricted to a particular interface on that CLIM. For more information on CIP, see the Cluster I/O Protocols (CIP) Configuration 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.

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.

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.

Note. The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).


Planning a Network Design ServerNet Connections

• 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 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).

For more information on adjusting settings so that routing is optimal, see Time Factors and Pathchange Messages on page 17-24.



Planning a Network Design Defining Paths Between Systems

Defining Paths Between SystemsEach 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

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 multi-line path. You cannot mix satellite-connect and Expand-over-IP lines with other line types. Expand-over-ServerNet 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


Planning a Network Design When to Use a Multi-Line Path

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 might 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.

Figure 3-1. Multi-Line Path With Eight Lines and Two SWAN Concentrators

VST025.vsd

$LINE1

$LINE2

$LINE3

$LINE4

$LINE5

$LINE6

$LINE7

$LINE8

$PATH1

SWAN

SWAN


Planning a Network Design When to Use a Multi-CPU Path

Figure 3-2 illustrates an eight-line configuration.

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 the processing for the path.

Figure 3-2. Multi-Line Path With Eight Lines and Eight SWAN Concentrators

VST026.vsd

$LINE1

$LINE2

$LINE3

$LINE4

$LINE5

$LINE6

$LINE7

$LINE8

$PATH2

SWAN

SWAN

SWAN

SWAN

SWAN

SWAN

$X25AM1 SWAN

$X25AM2 SWAN


Planning a Network Design When to Use a Multi-CPU Path

• 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 on configuring Expand-over-IP line-handler processes, see 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. Direct-connect lines, satellite-connect lines, Expand-over-X.25 connections, Expand-over-SNA connections, Expand-over-IP connections, and multi-line paths can be members of a multi-CPU path. Expand-over-ServerNet 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

VST054.vsd

CPU 0 CPU 1

CPU 2

CPU 4

CPU 3

LH

LH

LH

Node \A

CPU 0

CPU 1

CPU 2

CPU 3

LH

LH

LH

Node \B

CPU 4


Planning a Network Design Selecting Special Features

For more information on the multi-CPU paths, see Multi-CPU Feature on page 17-72.

Selecting Special FeaturesThe 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, see Multipacket Frame Feature on page 17-63.

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 these 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

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.


Planning a Network Design Congestion Control Feature

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, see Variable Packet Size Feature on page 17-67.

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, see Congestion Control Feature on page 17-69.

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• Mesh• Mixed

The star, tree, ring, bus, and mesh topologies are illustrated in Figure 3-4 on page 3-13. 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.



Planning a Network Design Common Network Topologies

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.

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, see Section 4, Planning for ServerNet Clusters.

Figure 3-4. Common Network Topologies

VST028

STARTREE

RING

MESH

BUS


Planning a Network Design Topology Limitations

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, see 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.

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 the above-mentioned topologies.

Topology Limitations

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.


Planning a Network Design Creating a Network Diagram

Creating a Network DiagramBefore 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 operating system subsystem (see the SCF Reference Manual for the Kernel Subsystem).

Figure 3-5. Network Diagram

VST030.vsd

SWAN SWAN

SWAN SWAN

SWAN

$PATH1

$LINE1

$LINE2

$LINE3

$PATH1

$LINE1

$LINE2

$LINE3

$LINEA $LINEB

$LINEC $LINEC

\LANode1

\DALLASNode 2

\BOISENode 3

\CHICAGONode 4

$LINEA $LINEB

SWANSWAN

SWAN


Planning a Network Design Creating a Network Diagram


4Planning 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 best-path route for data transmission to other nodes in the network, and monitor and logs changes in the status of the network and its nodes. For more information, see Section 6, Configuring the Network Control Process.

This section does not address every possible topology or identify every process that must be running on each system. For more information, see these manuals:

The topics described in this section include:

• Configuration Considerations for Expand and ServerNet Clusters on page 4-2

• ServerNet Clusters Coexisting With ATM or IP Networks on page 4-3


Cluster Switch Manual

6770 ServerNet Cluster Manual

6780 ServerNet Cluster 6780 Planning and Installation Guide


Planning for ServerNet Clusters Configuration Considerations for Expand and ServerNet Clusters

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.

• 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 Integrity NonStop nodes connected to a ServerNet cluster.

• As of G06.20, the Expand routing rules 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.

• 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; for more information on cable-distance restrictions in ServerNet clusters, see the ServerNet Cluster Manual (for the 6770 switch) and the ServerNet Cluster 6780 Planning and Installation Guide .

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 is 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 and ATM as the second best line, you


Planning for ServerNet Clusters ServerNet Clusters Coexisting With ATM or IP Networks

would set the LINETF as 1 for ServerNet, 2 for ATM, and a value greater than 2 for all the other paths.

For more information on time factors, including how they are specified and calculated, see Routing and Time Factors on page 17-22.

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:

• 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, S-series servers, and Integrity NonStop servers (the IP technology)

The topics addressed in this subsection include:

• Considerations for ServerNet Clusters Coexisting With ATM or IP on page 4-3

• Examples of ServerNet Clusters Coexisting With ATM or IP on page 4-4

For more information on IP and ATM adapters, see these manuals:


• TCP/IP (Parallel Library) Configuration and Management Manual


• ATM Configuration and Management Manual

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 more information on configuring time factors, see Routing and Time Factors on page 17-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 the OSM Service



Planning for ServerNet Clusters Examples of ServerNet Clusters Coexisting With ATM or IP

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.

Examples of ServerNet Clusters Coexisting With ATM or IP

• ServerNet Clusters Connected By ATM or IP Lines

• ServerNet Clusters Connected By a Single ATM or IP Line (Not Recommended)

• ServerNet Clusters Using Layered Topology With Connections to Nodes Outside the Cluster

ServerNet Clusters Connected By ATM or IP Lines

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-1 on page 4-5 shows two ATM-connected or IP-connected ServerNet clusters in a fault-tolerant configuration that incurs line hops. To modify this configuration for inter-ServerNet cluster communications without line hops, add ATM or IP connections within the ServerNet cluster as well.




ServerNet Clusters Connected By a Single ATM or IP Line (Not Recommended)

This topology is not recommended as a solution for enabling communication between two ServerNet clusters because of 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 because of 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.

Figure 4-1. ServerNet Clusters Connected by ATM or IP Lines


\BBB #2

ClusterSwitch

\AAA #1

\GGG #9\CCC #3 ClusterSwitch\DDD #7

\EEE #5\FFF #4

\HHH #6

\JJJ #8

5-Node ServerNet Cluster 4-Node ServerNet Cluster

ATM or IP

ATMor IP

ATM or IP

ATM or IP

VST062



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 Integrity NonStop NS-series systems. (See Figure 4-3 on page 4-7.)

This ServerNet cluster uses the layered topology (for more information on 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.

Figure 4-2. ServerNet Clusters Connected by a Single ATM or IP Line (Not Recommended)


\BBB #2

\FFF #4 \EEE #5

\AAA #1

\JJJ #8

ClusterSwitch\CCC #3 \HHH #6 Cluster

Switch\DDD #7 \GGG #9

5-Node ServerNet Cluster 4-Node ServerNet Cluster

ATMor IP

VST063



Figure 4-3. ServerNet Cluster Using Layered Topology With Connections to Nodes Outside the Cluster

VST075

ATM or IP

\WWW

\VVV

\UUU

\SSS

\TTT \BBC

\EEF

\AAB

\CCD

\DDE

\JJK

\IIJ

\HHI

\FFG

\GGH\OOO

\RRR

\NNN

\PPP

\QQQ

\Z456 \Z789ATM or IP ATM or IPATM or IP

ATM or IP

\LLL

\JJJ

\BBB

\EEE

\AAA

\CCC \III

\DDD

\GGG

\HHH

\FFF \MMM

Cluster SwitchGroup

Layer 1

Layer 2\Z123

Cluster SwitchGroup

Layer 1

Layer 2

Cluster SwitchGroup

Layer 1

Layer 2

ATM or IP

Zone 1

Zone 2 Zone 3



Part II consists of these 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 Multi-Line Paths


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:

• 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 16, Expand Modifiers. This section provides many modifiers for line-handler 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 17, 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.


Configuration Overview Summary of Configuration Steps

Summary of Configuration StepsConfiguring 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.

3.

Create a profile for the network control process at each node in the Expand network.

Create and start 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.

4. 5.

6.

Create profiles for the Expand line-handler processes. Create and start the Expand line-handler processes. Start the Expand lines.

For steps 4 through 6, information is located in one of these sections. Which section you select depends on the type of Expand line-handler process that you want to configure:

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 Multi-Line Paths


Configuration Overview Creating a Profile

Creating a ProfileA 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 on page 5-2. A comprehensive list of all the Expand modifiers is provided in Section 16, Expand Modifiers.

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 on WAN subsystem SCF commands, see the WAN Subsystem Configuration and Management Manual.

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


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 on WAN subsystem SCF commands, see the WAN Subsystem Configuration and Management Manual. For more information on Expand subsystem SCF commands, see Section 14, Subsystem Control Facility (SCF) Commands.

Starting the Expand Manager ProcessThe Expand subsystem requires that the Expand manager process ($ZEXP) be running during network operation. To start the Expand manager process, enter this 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 this 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


6Configuring the Network Control Process

This section explains how to configure and start the network control process ($NCP). Configuring and starting $NCP involves these 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 can 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 $NCPYou 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.

ADD Profile Command

To create a profile from the PEXPNCP profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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.

Note. You can also create a new profile from an existing profile, or you can create your own profile. For complete information about profiles, see the WAN Subsystem Configuration and Management Manual.

ADD PROFILE $ZZWAN.#profile_name , FILE $SYSTEM.SYSnn.PEXPNCP [, modifier_keyword [ modifier_value ] ] ...


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

This example creates a profile named NCPPROF1. The ALGORITHM modifier in the profile is set to 1 to specify split horizon. For more information, see ALGORITHM n on page 6-5 and Routing Algorithms on page 17-28.

-> ADD PROFILE $ZZWAN.#NCPPROF1, FILE $SYSTEM.SYS01.PEXPNCP, & ALGORITHM 1

Step 2: Create $NCPYou 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:

$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.

ADD DEVICE $ZZWAN.#NCP , IOPOBJECT $SYSTEM.SYSnn.NCPOBJ , PROFILE profile_name , CPU cpunum , ALTCPU altcpunum , TYPE (62,6) , RSIZE 1 [, modifier_keyword [ modifier_value ] ] ...


Configuring the Network Control Process Considerations

CPU cpunum

indicates the processor where $NCP will normally run. HP recommends that you configure $NCP to run in processors other than 0 and 1.

ALTCPU altcpunum

indicates the processor where the backup $NCP will normally run. HP recommends that you configure the backup $NCP to run in processors other than 0 and 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

This example creates $NCP. The MAXCONNECTS modifier for the device is set to 10.

-> ADD DEVICE $ZZWAN.#NCP, IOPOBJECT $SYSTEM.SYS01.NCPOBJ, & PROFILE NCPPROF1, CPU 2, ALTCPU 3, TYPE (62,6) RSIZE 1, & MAXCONNECTS 10


Configuring the Network Control Process Step 3: Start $NCP

Step 3: Start $NCPTo start $NCP, use the WAN subsystem SCF START DEVICE command. The command syntax is:

To make sure $NCP has started successfully, enter this command at the TACL prompt:

> STATUS $NCP

If $NCP was started successfully, you will see a display similar to Example 6-1:

If $NCP was not started successfully, this message will be displayed:

(Process does not exist)

$NCP ModifiersThese 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: 15,000 (2.5 minutes) Units: 0.01 seconds Range: 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 17-28.

START DEVICE $ZZWAN.#NCP

Example 6-1. SCF STATUS $NCP Command

System \NODEA

Process Pri PFR %WT Userid Program file Hometerm $NCP 2,26 199 P 011 255,255 $SYSTEM.SYS01.NCPOBJ $YMIOP.#CLCI Swap File Name: $SYSTEM.#0 $NCP B 3,24 199 P 011 255,255 $SYSTEM.SYS01.NCPOBJ $YMIOP.#CLCI Swap File Name: $SYSTEM.#0


Configuring the Network Control Process $NCP Modifiers

ALGORITHM n

Default: 0 (MSH) Units: Not applicable Range: 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 17-28.

AUTOMATICMAPTIMER n

Default: 1 (on) Units: Not applicable Range: 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 17-27.

CONNECTTIME n

Default: 0 Units: 0.01 seconds Range: 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 this 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 17-13 and TFs are described in Routing and Time Factors on page 17-22.



FRAMESIZE n

Default: 132 Units: Words Range: 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: 5 Units: Not applicable Range: 1 through 255

This modifier specifies the number of CONN requests that can be outstanding on each path from the system.

MAXTIMEOUTS n


This modifier specifies the maximum number of times $NCP will attempt a CONN request.

NETWORKDIAMETER n


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 17-30.

REBALTHRESHOLD n

Default: 0 Units: Seconds Range: -1 through 231 -1

This modifier specifies the threshold time for auto-rebalance. It also helps to enable and disable auto-rebalance. REBALTHRESHOLD can have the following values:



• -1, the auto-rebalance is switched off and the user must manually trigger rebalance.

• 0, the auto-rebalance occurs normally without taking into cognizance this modifier value.

• Greater than 0, the auto-rebalance occurs if the path has revived after being down beyond the time period mentioned in this modifier.


7Configuring 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 single-line 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 13, Configuring Multi-Line Paths.


Configuring Direct-Connect and Satellite-Connect Lines

Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the direct-connect or satellite-connect line-handler process to provide direct-connect or satellite-connect connectivity. These components are illustrated in Figure 7-1 and are explained in these subsections.

Figure 7-1. Direct-Connect and Satellite-Connect Connectivity Components

VST001

Processor

QIO SharedMemorySegment

TCP/IPProcess

LAN Driver and Interrupt Handlers(DIHs)

Y-Fabric

X-Fabric

WANSharedDriver

Direct-Connect orSatellite-Connect Line-

Handler Process

SWAN

SWAN

File-SystemInterface

LANAdapter

LANAdapter



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 more information on the QIO subsystem, see 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 input-output 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 more information on the WAN subsystem, see 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 LAN adapters and SWAN concentrators. The NonStop TCP/IP processes that support the adapter and SWAN concentrators are preconfigured and started during the system load sequence.

For more information on the NonStop TCP/IP and the NonStop TCP/IPv6 subsystems, see the TCP/IP Configuration and Management Manual and the TCP/IPv6 Configuration and Management Manual.

For more information on LAN adapters, see the LAN 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 more information on the SLSA subsystem, see 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.

For more information on the SWAN concentrator, see the WAN Subsystem Configuration and Management Manual.

Topology ConsiderationsIn 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 multi-CPU 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

VST041.vsd

Node \A Node \B

Node \C Node \D

CPU 0

LH

LH

CPU 0

CPU 1

LH

CPU 1 CPU 2

LH

LH

LH

CPU 0 CPU 1

LH LH

Multi-CPU Path

Single-Line Path

Single-Line Path

LH

CPU 2

LH

CPU 2Multiline Path



Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see 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 these steps:

Step 1: Find 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 on page 7-6 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.

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 direct-connect and satellite-connect line-handler processes; it is not meant to show the complete syntax of the SCF commands described. For more information, see these manuals:

• WAN Subsystem Configuration and Management Manual for WAN subsystem SCF commands

• Section 14, Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF commands

Note. This procedure assumes that a SWAN concentrator has been installed, configured, and started and has an available WAN line.



Step 1: Find an Available WAN Line

For more information on configuring and managing SWAN concentrators, see the WAN Subsystem Configuration and Management Manual.

Example 7-1. SCF STATUS ADAPTER Command

-> status adapter $zzwan.#*, sub all WAN Manager STATUS ADAPTER for ADAPTER \NODEA.$ZZWAN.#S01 State........... STARTED 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 : $X25A Line............ 1 : FREE WAN Manager STATUS PATH for PATH \NODEA.$ZZWAN.#S01.1.A State :......... STARTED MEDIA TYPE...... ETHERNET MEDIA ADDRESS... %H000000000000 WAN Manager STATUS PATH for PATH \NODEA.$ZZWAN.#S01.1.B State :......... STARTED MEDIA TYPE...... ETHERNET MEDIA ADDRESS... %H000000000000



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, see the WAN Subsystem Configuration and Management Manual.

This subsection describes how to create a profile using PEXQSSWN and PEXQSSAT.

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:

$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-12.

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

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 13, Configuring Multi-Line Paths.

ADD PROFILE $ZZWAN.#profile_name , FILE $SYSTEM.SYSnn.profile_filename [, modifier_keyword [ modifier_value ] ] ...



Examples

PEXQSSWN and PEXQSSAT profiles are described in Profile Modifiers on page 7-12.

Examples

In the first example, a profile named SLHSAT is created for a single-line satellite-connect 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

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 ProcessYou create a single-line direct-connect or satellite-connect line-handler process by adding it as a device to the WAN subsystem.

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:

$ZZWAN.#device_name

is the device name of the Expand line-handler process you want to add.

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 13, Configuring Multi-Line Paths.

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 ] ] ...



ADD DEVICE Command

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.


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.

CPU cpunumber

indicates the processor where this Expand line-handler process will normally run. 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 run. 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-5.

CLIP clipnum

is the CLIP number on the SWAN concentrator specified by concname that contains an available WAN line. For more information on identifying CLIP values, see Step 1: Find an Available WAN Line on page 7-5.

LINE linenum

is the number of an available WAN line on the CLIP specified by clipnum. For more information on identifying line numbers, see Step 1: Find an Available WAN Line on page 7-5. Valid values are 0 or 1.



Considerations

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 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-12.

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-12.

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



Step 4: Start the Line-Handler Process

In the next example, a device named $SAT1 is created for a single-line satellite-connect 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

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 ProcessTo start a single-line direct-connect or satellite-connect line-handler process, use the WAN subsystem SCF START DEVICE command. The command syntax is:

$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 LineTo 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:

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.

START DEVICE $ZZWAN.#device_name

START LINE $device_name



Profile Modifiers

Profile ModifiersThis 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.

Modifiers for Special Features

These 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• L4CWNDCLAMP modifier for the configuration of the congestion control transmit

window feature

For configuration considerations for these features, see Section 17, Subsystem Description. For more information on the advantages and disadvantages of these features, see Section 3, Planning a Network Design.

The PATHBLOCKBYTES, PATHPACKETBYTES, L4CONGCTRL_ON, SUPERPATH_ON, and L4CWNDCLAMP modifiers are described in detail in Section 16, Expand Modifiers.

PEXQSSWN and PEXQSSAT Modifiers

The disk file $SYSTEM.SYSnn.PEXQSSWN defines modifiers for single-line direct-connect 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, see Section 16, Expand Modifiers.

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 13, Configuring Multi-Line Paths.

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

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

L4CWNDCLAMP 32767 2000 through 2147483647

L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3


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

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 (direct-connect)

$SYSTEM.CSSnn. C1098P00 (satellite-connect)

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.




8Configuring 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.

NonStop TCP/IPv6 and CIP support IP version 6 (IPv6) communications. IPv6 supports a larger, 128-bit (16-byte) IP address that helps to address the growing number of machines and devices on the Internet. You can run NonStop TCP/IP, NonStop TCP/IPv6, and CIP on the same system.

For more information on NonStop TCP/IP, NonStop TCP/IPv6, and CIP see the TCP/IP Configuration and Management Manual, the TCP/IPv6 Configuration and Management Manual, and the Cluster I/O Protocols (CIP) 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 13, Configuring Multi-Line Paths.


Configuring Expand-Over-IP Lines Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the Expand-over-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 or CLuster I/O Module (CLIM). The TCP/IP process in this configuration can be either a NonStop TCP/IP, CIP (CIPSAM), or NonStop TCP/IPv6 (TCP6SAM) process. The architecture is different in CIP and NonStop TCP/IPv6 in that the TCP6SAM and CIPSAM processes do not provide the connectivity. For simplicity, they are shown here as being interchangeable with the NonStop TCP/IP process for Expand purposes. Also, in the CIP subsystem, the LAN adapter is actually a CLIM. For more information on the architecture of these subsystems, see the TCP/IPv6 Configuration and Management Manual, and the Cluster I/O Protocols (CIP) Configuration and Management Manual.

Note. The CLIM hardware component is supported only on systems running J06.04 and later J-series RVUs.

Figure 8-1. Expand-Over-IP Connectivity Components with a LAN Adapter or CLIM

Processor


Y-Fabric

X-Fabric

LAN Adapter/CLIM

Expand-over-IPLine-Handler

Process


TCP/IP

VST006.vsd


Configuring Expand-Over-IP Lines QIO Subsystem

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; NonStop TCP/IPv6 and CIP do not support ATM communications.

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 more information on the QIO enhancements that enable you to have more control over certain aspects of memory management, see Shared Memory Area for QIO on page 17-48. For more information on the QIO subsystem, see the QIO Configuration and Management Manual.

Figure 8-2. Expand-Over-IP Connectivity Components with ATM3SA

Processor

Y-Fabric

X-Fabric

ATM3SA

ATM Subsystem


Expand-over-IP

Line-Handler

Process

TCP/IP

Process

VST058.vsd


Configuring Expand-Over-IP Lines 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 more information on configuring and managing NonStop TCP/IP processes, see the TCP/IP Configuration and Management Manual.

NonStop TCP/IPv6 Process

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 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 NonStop TCP/IPv6 without LNP, the Expand line-handler process has access to all the IP addresses in the subsystem.) TCP/IPv6 provides performance enhancements and eliminates the need to configure the line-handler processes in the same CPU pair as the TCP/IP processes. In addition, NonStop TCP/IPv6 provides Ethernet failover capabilities. (NonStop TCP/IPv6 only supports LAN adapters.)

The line handler supports the 128-bit addressing scheme used in IPv6 communications in addition to the 32-bit addresses used by IPv4.

CIP Process

Cluster I/O Protocols (CIP) can also provide TCP/IP connectivity for the Expand-over-IP line-handler process. CIP can optionally provide support for IPv6 communications and has a feature similar to the NonStop TCP/IPv6 feature of 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. This feature is provided through the PROVIDER SCF object. CIP provides performance enhancements and eliminates the need to configure the line-handler processes in the same CPU pair as the TCP/IP processes. In addition, CIP provides Ethernet failover capabilities. (CIP only supports Ethernet adapters.)

The line handler supports the 128-bit addressing scheme used in IPv6 communications in addition to the 32-bit addresses used by IPv4.

Redundancy in Ethernet Adapters

Redundancy in Ethernet adapters (or CLIMs) and IP network routes can be applied by multi-line Expand-over-IP paths and multi-CPU paths, where the member paths are Expand-over-IP. These configurations offer multiple, parallel connections between a NonStop system and one of its neighbors. Use these configurations to get potentially


Configuring Expand-Over-IP Lines Local Area Network (LAN) Driver and Interrupt Handlers (DIHs)

greater bandwidth and fault tolerance. However, all elements, including the network itself, must have redundancy to obtain full benefit of the configurations.

The decision of which adapter (or CLIM) and path to apply for a particular Expand connection in conventional NonStop TCP/IP, CIP, and LNP-configured NonStop TCP/IPv6 is made explicitly by how you configure the adapters (or CLIMs), NonStop TCP/IP processes, and lines. This selection is independent of the external network. The adapters and lines are 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 fault-tolerance decisions made in Expand for multi-line IP paths can be disruptive rather than helpful.

NonStop TCP/IPv6 configured without LNP and CIP using the default (all interface) PROVIDER makes a dynamic choice of which adapter (or CLIM) and line to use, among any configured redundant assortment, based on the destination address of the IP connection and the best route to that destination. Unless network redundancy is provided implicitly in the destination addresses, the same adapter/line can be used for all connections to the same neighbor. NonStop TCP/IPv6 (in either LNP or non-LNP mode) and CIP can be configured with a redundancy feature at the adapter (or CLIM) 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 complete, 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 NonStop TCP/IPv6 or CIP subsystem automatically routes network traffic destined for the failed interface over its failover brother. Failover in the CIP subsystem has some restrictions that are not present in NonStop TCP/IPv6.

For more information on configuring Ethernet failover in NonStop TCP/IPv6, see the TCP/IPv6 Configuration and Management Manual. For information about configuring Ethernet failover in CIP, see the Cluster I/O Protocols (CIP) Configuration and Management Manual.


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 system-load sequence.

For more information on the SLSA subsystem, see the LAN Configuration and Management Manual.

Note. The CIP subsystem does not use the SLSA subsystem. See the Cluster I/O Protocols (CIP) Configuration and Management Manual for more information on the CIP architecture and migration considerations.


Configuring Expand-Over-IP Lines Asynchronous Transfer Mode (ATM) Subsystem

Asynchronous Transfer Mode (ATM) Subsystem

NonStop TCP/IP processes might 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 more information on the ATM subsystem, see the ATM Configuration and Management Manual.

LAN or ATM Adapters or the CLIM

You can use a G4SA, an ATM3SA, or a CLIM to provide connectivity to an IP network.

The CLIM is an HP ProLiant class server configured as a communications device. It provides Ethernet connectivity for J06.04 and later J-series RVUs on HP Integrity NonStop BladeSystems.

For more information on the G4SA, see the LAN Configuration and Management Manual. For more information on the ATM3SA, see the ATM Configuration and Management Manual. For more information on the CLIM, see the Cluster I/O Protocols (CIP) Configuration Management Manual.

Note. The CLIM hardware component is supported only on systems running J06.04 and later J-series RVUs.


Configuring Expand-Over-IP Lines Topology Considerations

Topology ConsiderationsIn 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 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 8-3. Expand-Over-IP Line-Handler Process Topology

IP Network

Single-Line Path

Node \A

CPU 1

LH

CPU 0

LH

CPU 2

LH

Node \C

CPU 0

LH

Node \B

CPU 1

LH

CPU 2

LH

IP Network

Multi-CPU Path

LH LH

CPU 3 CPU 0

Node \D

IP Network

Multiline Path

VST042.vsd


Configuring Expand-Over-IP Lines Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see Required Hardware and Software on page 8-2 for details), configuring and starting a single-line Expand-over-IP line-handler process involves these 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 Process and SUBNET for NonStop TCP/IPv6 Use

SCF interface to the NonStop TCP/IPv6 subsystem

Step 1 (C): Select a Process and SUBNET for CIP Use SCF interface to the CIP 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 Non-Stop TCP/IPv6 Use

SCF interface to the NonStop TCP/IPv6 subsystem

Step 2 (C): Identify an available UDP Port Number for CIP Use SCF interface to the CIP 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. For more information, see these manuals:



• Cluster I/O Protocols (CIP) Configuration and Management Manual

• WAN Subsystem Configuration and Management Manual

• Section 14, Subsystem Control Facility (SCF) Commands


Configuring Expand-Over-IP Lines Step 1 (A): Select a Process and SUBNET for NonStop TCP/IP Use

Step 1 (A): Select a Process and SUBNET for NonStop TCP/IP Use

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 Line-Handler Process.

To obtain a list of running NonStop TCP/IP processes, issue this 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-1 shows a sample result of the SCF LISTDEV TCPIP command.

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.

Note. These instructions assume that a NonStop TCP/IP process has already been created. For more information on creating NonStop TCP/IP processes, see the TCP/IP Configuration and Management Manual.

Example 8-1. SCF LISTDEV TCPIP Command

1-> SCF LISTDEV TCPIP SCF - T9082H01 - (01OCT04) (27APR04) - 12/09/2004 13:25:22 System \DRP25 (C) 1986 Tandem (C) 2003 Hewlett Packard Development Company, L.P. LDev Name PPID BPID Type RSize Pri Program 136 $ZTC13 3,485 2,485 (48,0 ) 32000 200 \DRP25.$SYSTEM.SYS55.TCPIP 147 $ZTC0 0,323 1,442 (48,0 ) 32000 200 \DRP25.$SYSTEM.SYS55.TCPIP 430 $ZTC12 3,481 2,484 (48,0 ) 32000 200 \DRP25.$SYSTEM.SYS55.TCPIP 434 $ZTC10 2,478 3,478 (48,0 ) 32000 200 \DRP25.$SYSTEM.SYS55.TCPIP 494 $ZTC11 2,481 3,479 (48,0 ) 32000 200 \DRP25.$SYSTEM.SYS55.TCPIP


Configuring Expand-Over-IP Lines Select a SUBNET for NonStop TCP/IP

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 Expand-over-IP line-handler process. Example 8-2 shows an example of an SCF INFO SUBNET command for a NonStop TCP/IP process named $ZTC01.

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. This SCF ADD SUBNET command shown 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

This SCF ADD SUBNET command shown 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

Example 8-2. SCF INFO SUBNET Command

2-> INFO SUBNET $ZB01A.#* TCPIP Info SUBNET \NODEA.$ZB01A.* Name Devicename *IPADDRESS TYPE *SUBNETMASK SuName QIO *R

#LOOP0 \NODEB.$NOIOP 127.0.0.1 LOOP-BACK %HFF000000 OFF N #SN1 \NODEA.$LAN01 172.16.35.15 ETHERNET %HFFFFFF00 ON N #SN2 \NODEA.$AM1 172.16.192.20 ATM %HFFFFFF00 ON N


Configuring Expand-Over-IP Lines Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use

After the SUBNET is defined, it must be started using the SCF START SUBNET command. This SCF START SUBNET command shown starts the SUBNET named #SN1:

-> START SUBNET $ZTC01.#SN1

For more information on creating SUBNETs, see the TCP/IP Configuration and Management Manual.

Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use

Step 1 (B) 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 this SCF command:

> INFO SUBNET $ZZTCP.*, DETAIL

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.

Note. These instructions assume that a NonStop TCP/IPv6 environment has already been started. For more information on starting a NonStop TCP/IPv6 environment, see the TCP/IPv6 Configuration and Management Manual.

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.


Configuring Expand-Over-IP Lines Select a SUBNET for NonStop TCP/IPv6 Use

Example 8-3 shows a sample result of the SCF INFO SUBNET, DETAIL command.

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 TCP6SAM process shown in the LNP field is $ZSAM1. That means $ZSAM1 is the

Example 8-3. SCF INFO SUBNET, DETAIL Command

TCPIPV6 Detailed Info SUBNET \NODEA.$ZZTCP.#ZPTMF.*

AF_INET:Name Devicename *IPADDRESS/DST_IPADDR TYPE *SUBNETMASK *R LNPSN116 \NODEA.FEF0A 172.10.188.140 ETHERNET %HFFFFFF00 N 0 Trace Status ........ OFF Trace Filename ...... Interface MTU ....... 1500 ---Multicast Groups--- ---State--- 224.0.0.1 STARTED LNP... $ZB01A Index... 1LOOP0 127.0.0.1 LOOP %HFF000000 N 0 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 TYPE LNPSN117 \NODEA.FEF0A fe80::a00:8eff:fe02:46e ETHERNET 0 *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


Configuring Expand-Over-IP Lines Select a TCP6SAM Process

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. 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 this 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 is a conventional NonStop TCP/IP process whereas a program name of TCP6SAM means it is a NonStop TCP/IPv6 process. Example 8-4 shows a sample result of the SCF LISTDEV TCPIP command.

In the above example, all the processes 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-3 on page 8-12, 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 these steps:


1-> listdev tcpip LDev Name PPID BPID Type RSize Pri Program 256 $ZSAM0 0,416 1,389 (48,0 ) 57344 201 \DRP25.$SYSTEM.SYS55.TCP6SAM 259 $ZSAM1 1,390 0,417 (48,0 ) 57344 201 \DRP25.$SYSTEM.SYS55.TCP6SAM 260 $ZSAM2 2,310 3,303 (48,0 ) 57344 201 \DRP25.$SYSTEM.SYS55.TCP6SAM 261 $ZSAM3 3,304 2,311 (48,0 ) 57344 201 \DRP25.$SYSTEM.SYS55.TCP6SAM


Configuring Expand-Over-IP Lines Creating an Ethernet Subnet

1. Issue the SCF INFO SUBNET $ZZTCP.*, DETAIL command.

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-3 on page 8-12 that $ZSAM1 is the only TCP6SAM process associated with an LNP so $ZSAM2, shown in Example 8-4 on page 8-13, 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 this 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 this example starts the SUBNET named SN1:

-> START SUBNET $ZZTCP.*.SN1

For more information on creating SUBNETs in the NonStop TCP/IPv6 environment, see the TCP/IPv6 Configuration and Management Manual.

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.


Configuring Expand-Over-IP Lines Step 1 (C): Select a Process and SUBNET for CIP Use

Step 1 (C): Select a Process and SUBNET for CIP Use

Step 1 (C) is for use with CIP only.

Select a CIPSAM Process

The CIP socket access method (CIPSAM) is a process that provides programs access to the CIP environment. Use a CIPSAM process name for the ASSOCIATEDEV modifier in Step 4: Create the Line-Handler Process while configuring Expand-over-IP with CIP environment.

To obtain a list of running CIPSAM processes, run this SCF LISTDEV command:

-> LISTDEV TCPIP

The SCF LISTDEV command lists all the TCP/IP processes. A program name in the SCF LISTDEV display of CIPSAM indicates a CIP socket access method process. Note the process name and use Example 8-5 that shows a sample result of the SCF LISTDEV TCPIP command.

In this example, there is one CIPSAM process called $ZSAM0.

Obtain an IP Address to associate with your Expand Line- Handler Process

To obtain an IP address for Expand communications, issue the SCF INFO SUBNET command for the INFO process.

->INFO SUBNET $ZSAM0.*

From the displayed devices, select an Ethernet device and note the IP address. Example 8-6 shows the output of the SCF INFO SUBNET command.

Note. The following instructions assume that a CIP environment has already been started. For information on starting a CIP environment, see the Cluster I/O Protocols (CIP) Configuration and Management Manual.


1-> listdev tcpip LDev Name PPID BPID Type RSize Pri Program 256 $ZSAM0 0,416 1,389 (48,0 ) 57344 201 \SYSNAME.$DATA.CIPSLH.CIPSAM


Configuring Expand-Over-IP Lines Obtain an IP Address to associate with your Expand Line- Handler Process

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.

In this example, we use SUBNET #SN0002 and its IP address, 172.17.190.101.

Example 8-6. SCF INFO SUBNET $ZSAM0

CIP Info SUBNET $\MYSYS.$ZSAM0.*

Name Devicename *IPADDRESS TYPE *SUBNETMASK SuName QIO *R

#SN0001 lo 127.0.0.1 LOOP-BACK %HFF000000 OFF N

#SN0002 DL395N.eth1 172.17.190.101 ETHERNET %HFFFFFF00 ON N

#SN0003 DL385N.ETH2 172.17.190.102 ETHERNET %HFFFFFF00 ON N



#SN0007 DL385Q.BOND0 172.17.190.81 ETHERNET %HFFFFFF00 ON N

#SN0008 DL385Q.BOND1 172.17.190.83 ETHERNET %HFFFFFF00 ON N

Note. Only IPv4 addresses are displayed with the CIP SCF INFO SUBNET command. If you want to use an IPv6 address, obtain one by using the SCF STATUS CLIM, DETAIL command. This command displays both IPv4 and IPv6 addresses configured on each interface.


Configuring Expand-Over-IP Lines Step 2 (A): Identify an Available UDP Port Number

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.

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:

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

Example 8-7. SCF STATUS PROCESS Command

3-> STATUS PROCESS $ZTC01 TCPIP Status PROCESS \NODEA.$ZTC01 Status: STARTED PPID............ ( 0,311) BPID................... ( 1,292) Proto State Laddr Lport Faddr Fport SendQ RecvQ TCP ESTAB 172.16.35.15 1057 155.186.68.137 5000 0 0 TCP LISTEN 0.0.0.0 9000 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 2563 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 telnet 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 ftp 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 finger 0.0.0.0 * 0 0 TCP LISTEN 0.0.0.0 echo 0.0.0.0 * 0 0 UDP 0.0.0.0 1029 0.0.0.0 * 0 0 UDP 0.0.0.0 68 0.0.0.0 * 0 0 UDP 0.0.0.0 67 0.0.0.0 * 0 0 UDP 0.0.0.0 69 0.0.0.0 * 0 0


Configuring Expand-Over-IP Lines Step 2 (B): Identify an Available UDP Port Number for NonStop TCP/IPv6 Use

you define the Expand-over-IP line-handler process in Step 4: Create the Line-Handler Process.

Step 2 (B): Identify an Available UDP Port Number for NonStop 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, identify an available UDP port number for the IP address you selected in Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use.

You can use the SCF STATUS MON 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 this SCF command:

> STATUS MON $ZZTCP.*

Example 8-8 shows a sample result of the SCF STATUS MON command.

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.


Configuring Expand-Over-IP Lines Step 2 (B): Identify an Available UDP Port Number for NonStop TCP/IPv6 Use

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 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.

Example 8-8. SCF STATUS MON Command

3-> STATUS MON $ZZTCP.* TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM0 Status: STARTED, MASTER PID............ ( 0,275) Proto State Laddr Lport Faddr Fport SendQ RecvQ UDP 16.107.187.84 5550 0.0.0.0 * 0 0 TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM1 Status: STARTED PID............ ( 1,287) Proto State Laddr Lport Faddr Fport SendQ RecvQ TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM2 Status: STARTED PID............ ( 2,293) Proto State Laddr Lport Faddr Fport SendQ RecvQ UDP 16.107.187.84 21600 0.0.0.0 * 0 0 UDP --------------- 5050 --------------- * 0 0 Laddr fe80::a00:8eff:fe00:897b Faddr :: TCPIPV6 Status MON \NODEC.$ZZTCP.#ZPTM3 Status: STARTED PID............ ( 3,271) Proto State Laddr Lport Faddr Fport SendQ RecvQ



Configuring Expand-Over-IP Lines Step 2 (C): Identify an available UDP Port Number for CIP Use

Step 2 (C): Identify an available UDP Port Number for CIP 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 must identify an available UDP port number for the IP address you selected in Step 1 (C): Select a Process and SUBNET for CIP Use.

You can use the CIP SCF LISTOPENS MON to determine which UDP port numbers are already in use for a particular IP address.

->LISTOPENS MON $ZZCIP.*

Example 8-9 shows a sample result of the SCF LISTOPENS MON command.

UDP port numbers are identified by UDP in the Proto field. The UDP port numbers that are in use are displayed in the Lport field. As shown in Example 8-9, the UDP port number 5010 is in use. Based on the information shown by the LISTOPENS 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.

Example 8-9. SCF LISTOPENS MON Command

->LISTOPENS MON $ZZCIP.*

CIP Listopens MON \MYSYS.$ZZCIP.ZCM01

Openers Ppid Bpid Proto Lport Provider CLIM

\MYSYS. $ZTN2 1,23 0,24 TCP telnet TC2 CLIM3

\MYSYS.$RMAIL 1,162 TCP 10293 ZTC2 CLIM3

\MYSYS.$MYWEB 1,333 0,312 TCP http ZTC0 CLIM1

\MYSYS.$MYWEB 1,333 0,312 TCP http ZTC0 CLIM1

CIP Listopens MON \MYSYS.$ZZCIP.ZCM02

Openers Ppid Bpid Proto Lport Provider CLIM

\MYSYS.$ZTN0 2,24 3,24 TCP telnet ZTC0 CLIM1



\MYSYS.$TEST6 2,325 TCP 10513 ZTC1 CLIM2

\MYSYS 2,210 UDP 5010 ZTC0 CLIM1



Configuring Expand-Over-IP Lines Step 2 (C): Identify an available UDP Port Number for CIP Use

The LISTOPENS MON command does not display which IP addresses the port numbers are associated with. However, the LISTOPENS PROVIDER $ZZCIP.<provider-name>, DETAIL command displays IP addresses with the ports for the specified Provider. You might need the INFO PROVIDER $ZZCIP.* command to find the PROVIDER name associated with the CIPSAM name.


Configuring Expand-Over-IP Lines 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, see the WAN Subsystem Configuration and Management Manual.

This subsection shows you how to create a profile using PEXQSIP.

ADD Profile Command

To create a profile from the PEXQSIP profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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-32.

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-32.

Note. Different profiles are provided for Expand-over-IP lines that are part of a multi-line path; these profiles are described in Section 13, Configuring Multi-Line Paths.



Configuring Expand-Over-IP Lines Example

Example

In this example, a profile named SLHIP is created for a single-line Expand-over-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 ProcessYou create a single-line Expand-over-IP line-handler process by adding it as a device to the WAN subsystem.

ADD DEVICE Command

To create an Expand-over-IP line-handler process, use the WAN subsystem SCF ADD DEVICE command. The command syntax is:

$ZZWAN.#device_name

specifies, via the WAN subsystem, the device name of the Expand line-handler process to add.



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 13, Configuring Multi-Line Paths.

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 ] ] ...


Configuring Expand-Over-IP Lines ADD DEVICE Command



CPU cpunumber

indicates the processor where this Expand line-handler process runs. This must be the same processor as configured for the primary NonStop TCP/IP process.

If you are using NonStop TCP/IPv6 or CIP, you need not have the line-handler on the same CPU as the TCP6SAM or CIPSAM process. There is typically a monitor process in each CPU. The line-handler process must be on the CPU that contains a monitor process.

ALTCPU altcpunumber

indicates the processor where the backup Expand line-handler process runs. This must be the same processor as that configured for the NonStop TCP/IP process.

If you are using NonStop TCP/IPv6 or CIP, you need not have the line-handler on the same CPU as the TCP6SAM or CIPSAM process. There is typically a monitor process in each CPU. The line-handler process must be on the CPU that contains a 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 single-line Expand-over-IP line-handler processes.

RSIZE rsize


ASSOCIATEDEV tcpip_process

is a required modifier that specifies the device name of the NonStop TCP/IP, CIPSAM, 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.

{IPVER_IPV4 | IPVER_IPV6}

specifies whether the destination and source addresses are IPv4 or IPv6. The default is IPv4. DESTIPADDR and SRCIPADDR are required if IPVER is IPV4 (the default). V6DESTIPADDR and V6SRCIPADDR are required if IPVER is IPV6. (This attribute applies to NonStop TCP/IPv6 and CIP only.)


Configuring Expand-Over-IP Lines ADD DEVICE Command

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, CIPSAM, 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, Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use, or Step 1 (C): Select a Process and SUBNET for CIP 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 address is 0.0.0.1.

SRCIPPORT src_ipport

is a required modifier that specifies the UDP port number used by this Expand-over-IP line-handler process. This is the port number you selected in Step 2 (A): Identify an Available UDP Port Number, Step 2 (B): Identify an Available UDP Port Number for NonStop TCP/IPv6 Use, or Step 2 (C): Identify an available UDP Port Number for CIP Use. 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, Step 1 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use, and Step 1 (C): Select a Process and SUBNET for CIP Use. It is not validated and need not be accessible. The default address 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, Step 2 (B): Identify an Available UDP Port Number for NonStop TCP/IPv6 Use, and Step 2 (C): Identify an available UDP Port Number for CIP Use. Valid values are in the range 0 through 65534. The default value 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 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use or Step 1 (C): Select a Process and SUBNET for CIP


Configuring Expand-Over-IP Lines Considerations

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 and CIP only.)

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 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use or Step 1 (C): Select a Process and SUBNET for CIP 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


Modifier names in the PEXQSIP profile are listed in Profile Modifiers on page 8-32.

modifier_value


Default values and ranges of values for modifiers in the PEXQSIP profile are described in Profile Modifiers on page 8-32.

Considerations




Configuring Expand-Over-IP Lines Example

Example

In this example, a device named $IPLIN1 is created for a single-line Expand-over-IP line-handler process. The PATHPACKETBYTES modifiers are recommended for Expand-over-IP lines. (The default for the L4EXTPACKETS_ON and L4CONGCTRL_ON modifiers is ON.)

-> 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 because 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 this 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 ProcessTo start a single-line Expand-over-IP line-handler process, use the WAN subsystem SCF START DEVICE command. The command syntax is:

device_name

is the device name of the Expand-over-IP line-handler process.




Configuring Expand-Over-IP Lines Step 6: Start the Line

Step 6: Start the LineTo start an Expand-over-IP line, use the Expand subsystem SCF START LINE command. The command syntax is:

device_name

is the device name of the Expand-over-IP line-handler process.


Add a Configured Tunnel for an Expand LineThese 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.

Example 8-10 shows how to configure an Expand line using configured tunnel for \NodeB.


Note. These examples apply to NonStop TCP/IPv6 only.

Example 8-10. \NodeB: Configure an Expand-over-TCP/IPv6 Line Using Config-ured-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


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-12 shows how to configure an Expand line using configured-tunnel for \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. \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


Configuring Expand-Over-IP Lines Add a Configured Tunnel for an Expand Line for CIP

Example 8-13 shows how to add an Expand line from \NodeC to \NodeB.

Add a Configured Tunnel for an Expand Line for CIP

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 remaining examples are configured at the host \NodeC.

Example 8-14 shows how to configure an Expand line using configured-tunnel for \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

Note. These examples apply to CIP only.

Example 8-14. TACL Macro \NodeB: Configure an Expand-over-CIP Line With a Tunnel

climcmd clim1 climconfig tunnel -add mytun1 -ipaddress 3FFE:A::A00:8EFF:FE03:812E -netmask 64 -endpoint 15.76.217.111 -local 15.76.217.35 -intf eth1 == Use ipv6address of configured-tunnel for ipv6gateway route. climcmd clim1 climconfig route -add mytun1 -net -target abcd:1234::0 -netmask 64

climcmd clim1 ifstart mytun1


Configuring Expand-Over-IP Lines Add a Configured Tunnel for an Expand Line for CIP

Example 8-15 shows how to add an Expand line from \NodeB to \NodeC.

Example 8-16 shows how to configure an Expand line using a tunnel for \NodeC.

Example 8-15. 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 15.76.217.111, destipport 5050, & srcipaddr 15.76.217.35 , 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-16. \NodeC: Configure an Expand-over-CIP Line Using a Tunnel



Configuring Expand-Over-IP Lines Profile Modifiers

Example 8-17 shows how to add an Expand line from \NodeC to \NodeB.

Profile ModifiersThis 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.

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.

Example 8-17. Add an Expand Line to \NodeB


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 13, Configuring Multi-Line Paths.


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 17, Subsystem Description, before using this modifier. The L4CONGCTRL_ON modifier is described in detail in Section 16, Expand Modifiers.

PATHPACKETBYTES n

Default: 1024 Units: Bytes Range: 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 17, Subsystem Description, before using this modifier. The PATHPACKETBYTES modifier is described in detail in Section 16, Expand Modifiers.


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. The L4CWNDCLAMP modifier is provided in the PEXQSIP profile to enable you to configure the congestion control transmit window feature.

For configuration considerations for all special features, see Section 17, Subsystem Description. For more information on the advantages and disadvantages of each feature, see Section 3, Planning a Network Design.


PEXQSIP Modifiers

The disk file $SYSTEM.SYSnn.PEXQSIP defines modifiers for single-line Expand-over-IP line-handler processes.

Table 8-1 on page 8-34 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.


Configuring Expand-Over-IP Lines PEXQSIP Modifiers

For a complete description of the modifiers listed in this table, see Section 16, Expand Modifiers.

Table 8-1. PEXQSIP Modifiers for Expand-over-IP Lines (page 1 of 2)


AFTERMAXRETRIES_DOWN

AFTERMAXRETRIES_PASSIVE 3

ASSOCIATEDEV1 None Any 8-character string

COMPRESS_OFF

COMPRESS_ON 3

CONNECTTYPE_ACTIVEANDPASSIVE 3

CONNECTTYPE_PASSIVE

DESTIPADDR2 0.0.0.0 Any 36-character string

DESTIPPORT1 1024 0 through 65534

DOWNIFBADQUALITY_ON




IPVER_IPV4 3IPVER_IPV6


L4CONGCTRL_OFF

L4CONGCTRL_ON 3


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3






MAXRECONNECTS 0 0 through 32767


OSSPACE 32767 3072 to 32767

OSTIMEOUT 300 10 to 32767

PATHBLOCKBYTES4 0 0 through 9152 or 9180

PATHPACKETBYTES4 1024 0 through 9152 or 9180





QUALITYTIMER 60 0 to 77600 (12hrs)

RETRYPROBE 19 1 through 255


SPEED 0 0 through 224000


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


1. This is a required modifier.

2. This is a required modifier. For IP address syntax, see the TCP/IPv6 Configuration and Management Manual.


4. The maximum value is actually 9180, but for performance it is best to use whole multiples of 32, which would cause a 9152 maximum.

Table 8-1. PEXQSIP Modifiers for Expand-over-IP Lines (page 2 of 2)



9Configuring 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 13, Configuring Multi-Line Paths.

Note. Multi-line paths are not recommended. For fault tolerance (that is, a backup line) a multi-CPU path (superpath) is the recommended approach.


Configuring Expand-Over-ATM Lines Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the Expand-over-ATM line-handler process to provide Expand-over-ATM connectivity. These components are illustrated in Figure 9-1 and are explained in these subsections.

QIO Subsystem


For more information on QIO enhancements that enable you to have more control over certain aspects of memory management, see Shared Memory Area for QIO on page 17-48. For more information on the QIO subsystem, see the QIO Configuration and Management Manual.

Figure 9-1. Expand-Over-ATM Connectivity Components

VST055.vsd

Processor

Y-Fabric

X-Fabric

QIOSharedMemorySegment

ATM3SA

ATM Subsystem orSLSA Subsystem

Expand-Over-ATMLine-Handler

Process


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 User-Network Interface (UNI) Specification Version 3.0 over a 155 Mbps SONET STS-3c connection.

For more information on configuring and managing the ATM subsystem, see the ATM Configuration and Management Manual.

SLSA Subsystem

The SLSA subsystem provides access to parallel LAN and WAN I/O. The SLSA subsystem provides access to ServerNet adapters, multifunction I/O-board Ethernet adapters, the ServerNet wide area network (SWAN) concentrator, and Expand-over-ATM line handlers.


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 more information on the ATM3SA, see the ATM Configuration and Management Manual.


Configuring Expand-Over-ATM Lines Topology Considerations

Topology ConsiderationsIn 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 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 9-2. Expand-Over-ATM Line-Handler Process Topology

VST056.vsd

Single-line Path

Node \A

CPU 1

LH

CPU 0

LH

CPU 2

LH

Node \C

CPU 0

LH

Node \B

CPU 1

LH

CPU 2

LH

Multi-CPU Path

LH LH

CPU 3 CPU 1Multiline Path

Node \D


Configuring Expand-Over-ATM Lines Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see Required Hardware and Software on page 9-2 for details), configuring and starting a single-line Expand-over-ATM line-handler process involves these steps:

Step 1: Identify the ATM Connection

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.

Step Tool Used

Step 1: Identify the ATM Connection SCF interface to the ATM 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. For more information, see:

• ATM Configuration and Management Manual for ATM subsystem commands


• Subsystem Control Facility (SCF) Commands, for Expand subsystem SCF commands

Note. This procedure assumes that an ATM3SA has already been installed and configured. For complete information about installing and configuring an ATM3SA, see the ATM Configuration and Management Manual.


Configuring Expand-Over-ATM Lines Configuring an Expand Line-Handler Process That Uses a PVC

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.

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 this 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.

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

Example 9-1. SCF INFO PVC Command

1-> INFO PVC $AM1.#IP.* ATM Info PVC Name *VPI *VCI $AM1.#IP.PVC1 23 35

Note. #IP is currently the only supported SAP.


Configuring Expand-Over-ATM Lines Configuring an Expand Line-Handler Process That Uses an SVC

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 Expand-over-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.

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:

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 this ATM address during Expand-over-ATM line-handler configuration:

47000580FFE1000000F21A29EB0000000001B381

Example 9-2. ATM Subsystem SCF INFO LINE, DETAIL Command

3-> INFO LINE $AM1, DETAIL ATM Detailed Info LINE \NODEA.$AM1 *ATMADDR................. ISONSAP: 47 00 05 80 FF E1 00 00 00 F2 1A 29 EB 00 00 00 00 01 B3 00H Registered Atm Address... ISONSAP: 47 00 05 80 FF E1 00 00 00 F2 1A 29 EB 00 00 00 00 01 B3 00H *UNIVERSION.............. 3.0 UME *UMECOMMUNITY............ *UMEVPI. ................ 1 *UMEVCI................... 16 *MAXPVCVPI............... 100 *MAXPVCVCI...... ......... 100 PHYSICAL LAYER Phys Layer Media Type.... MULTIMODE Phys Layer Xmit Type .... SONET ATM LAYER *MAXVPCS................. 100 *MAXVCCS.................. 1000 *MAXVPIBITS.............. 8 *MAXVCIBITS............... 10 *UNIPORTTYPE............. PRIVATE


Configuring Expand-Over-ATM Lines Configuring an Expand Line-Handler Process That Uses an SVC

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.

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.

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........ NOT_SET Framesize....... 132 -Rsize........... 3 -Speed........ *LinePriority.... 1 StartUp......... OFF Delay......... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00 *Txwindow........ 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE *Timerreconnect 0:00:30.00 *Retryprobe...... 3 *Timerprobe.... 0:00:30.00 *Associatedev.... $AM1 *Associatesubdev #IP *Timerinactivity 0:00:00.00 ConnEp....... %H00000000 ListenEp.... %H00000000 *CallType...... SVC *AtmSel...... %H80 *DestAtmAddr.. (ISONSAP:%H47009181000100006170597C0140000C80001081)

Note. You cannot display the selector bytes currently in use using the ATM subsystem SCF INFO LINE command (shown in Example 9-2 on page 9-7) because the ATM subsystem SCF INFO LINE command only displays static configuration information.


Configuring Expand-Over-ATM Lines Configuring an Expand Line-Handler Process That Uses ATMSAP

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.

For more information on ATMSAP objects, including their management by the SCF ABORT, ADD, ALTER, DELETE, INFO, NAMES, START, STATS, STATUS, and STOP commands, see 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. 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. 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.

Figure 9-3. Expand and ATMSAP

Expand LHProcess

LINE LIF

CPU

ATMSAP

ATM3SA

ATMSAP

ATM3SA

CPU

Expand LHProcess

LINELIF

VST003.vsd


Configuring Expand-Over-ATM Lines Configuring an Expand Line-Handler Process That Uses ATMSAP

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-5 shows examples of altering the modifier CALLTYPE and the LIFNAME of an Expand-over-ATM line-handler process named $ATM2BAT.

Example 9-4. Expand Subsystem SCF INFO LINE, DETAIL Command for ATMSAP

-> INFO LINE $ATM2BAT, DETAIL EXPAND Detailed Info LINE $ATM2BAT (LDEV 613) L2Protocol Net^Atm TimeFactor... 26K *SpeedK... OC3 Framesize.... 132 -Rsize.... -Speed... *LinePriority... 1 StartUp... OFF Delay... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer 0:01:00.00 *Txwindow... 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE *Timerreconnect 0:00:30.00 *Retryprobe……. 3 *Timerprobe… 0:00:30.00 *CallType... ATMSAP *LifName.. ATM2LIF *Timerinactivity 0:00:00.00

Example 9-5. Altering the CALLTYPE Modifier and LIFNAME

-> ALTER LINE $ATM2BAT, CALLTYPE ATMSAP

-> ALTER LINE $ATM2BAT, LIFNAME LIFEXP01


Configuring Expand-Over-ATM Lines 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, see the WAN Subsystem Configuration and Management Manual.

This subsection shows you how to create a profile using PEXQSATM.

ADD Profile Command

To create a profile from the PEXQSATM profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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.


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-over-ATM 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-18.

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-18.

Note. Different profiles are provided for Expand-over-ATM lines that are part of a multi-line path; these profiles are described in Section 13, Configuring Multi-Line Paths.



Configuring Expand-Over-ATM Lines Example

Example

In this example, a profile named SLHATM is created for a single-line Expand-over-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

Step 3: Create the Line-Handler ProcessYou create a single-line Expand-over-ATM line-handler process by adding it as a device to the WAN subsystem.

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 this command syntax if the Expand-over-ATM line-handler process will use a PVC connection:

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 13, Configuring Multi-Line Paths.

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 ] ] ...


Configuring Expand-Over-ATM Lines ADD DEVICE Command

Syntax for SVC Connections

Use this command syntax if the Expand-over-ATM line-handler process will use an SVC connection:

Syntax for ATMSAP Connections

Use this command syntax if the Expand-over-ATM line-handler process will use an ATMSAP connection:

$ZZWAN.#device_name






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 ] ] ...

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 ] ] ...



CPU cpunumber

indicates the processor where this Expand line-handler process will normally run.

ALTCPU altcpunumber

indicates the processor where the backup Expand line-handler process will normally run.

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 single-line Expand-over-ATM line-handler processes.

RSIZE rsize


ASSOCIATEDEV atm-line

specifies the device name of the ATM line you want to associate with this Expand-over-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, null- terminated, and case-sensitive.

This modifier is only applicable to ATMSAP connections using the SLSA subsystem.



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)


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


Modifier names in the PEXQSATM profile are listed in Profile Modifiers on page 9-18.


Configuring Expand-Over-ATM Lines Considerations

modifier_value


Default values and ranges of values for modifiers in the PEXQSATM profile are described in Profile Modifiers on page 9-18.

Considerations



Examples

In this 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


-> 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 Expand-over-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)


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-over-ATM 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 ProcessTo start a single-line Expand-over-ATM line-handler process, use the WAN subsystem SCF START DEVICE command. The command syntax is:

$ZZWAN.device_name

specifies, via the WAN subsystem, the device name of the Expand-over-ATM line-handler process.


Step 5: Start the LineTo start an Expand-over-ATM line, use the Expand subsystem SCF START LINE command. The command syntax is:

device_name

is the device name of the Expand-over-ATM line-handler process.





Configuring Expand-Over-ATM Lines Profile Modifiers

Profile ModifiersThis 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.


Recommended modifiers are modifiers that should be used to obtain optimum performance and efficiency.

L4CONGCTRL_ON

Default: ON 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-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 17, Subsystem Description, before using this modifier. The L4CONGCTRL_ON modifier is described in detail in Section 16, Expand Modifiers.

PATHPACKETBYTES n

Default: 1024 Units: Bytes Range: 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 17, Subsystem Description, before using this modifier. The PATHPACKETBYTES modifier is described in detail in Section 16, Expand Modifiers.

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 13, Configuring Multi-Line Paths.


Configuring Expand-Over-ATM Lines Modifiers for Special Features

L4EXTPACKETS_ON

Default: ON Units: Not applicable Range: 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 16, Expand Modifiers.


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. The L4CWNDCLAMP modifier is provided in the PEXQSATM profile to enable you to configure the congestion control transmit window feature.

For configuration considerations for all special features, see Section 17, Subsystem Description. For more information on the advantages and disadvantages of each feature, see Section 3, Planning a Network Design.


PEXQSATM Modifiers

The disk file $SYSTEM.SYSnn.PEXQSATM defines modifiers for single-line Expand-over-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, see Section 16, Expand Modifiers.

Table 9-1. PEXQSATM Modifiers for Expand-over-ATM Lines (page 1 of 3)





ATMSEL2 %H80 0 through %HFF

CALLTYPE_PVC3 3

CALLTYPE_SVC2


Configuring Expand-Over-ATM Lines PEXQSATM Modifiers

CALLTYPE_ATMSAP4

COMPRESS_OFF7

COMPRESS_ON 3


CONNECTTYPE_PASSIVE

DESTATMADDR2 (ISONSAP: %H00...)

Any valid 20-byte ISO NSAP ATM address

DOWNIFBADQUALITY_ON





L4CONGCTRL_OFF

L4CONGCTRL_ON 3


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3




LIFNAME5 None Any 8-character string





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)


PVCNAME3 None Any 8-character string


QUALITYTIMER 60 0 to 77600 (12hrs)







SPEED 0 0 or 1200 through 224000


STARTUP_OFF 3

STARTUP_ON

SUPERPATH_OFF 3

SUPERPATH_ON





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.


6. The maximum value is actually 9180, but for performance it is best to use whole multiples of 32, which would cause a 9152 maximum.

7. Although the default value is COMPRESS_ON, we recommend that you turn it off for ATM.




10Configuring 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 13, Configuring Multi-Line Paths.


Configuring Expand-Over-X.25 Lines Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the Expand-over-X.25 line-handler process to provide Expand-over-X.25 connectivity. These components are illustrated in Figure 10-1 and are explained in these subsections.

Figure 10-1. Expand-Over-X.25 Line-Handler Process Components

VST004

Processor


TCP/IPProcess


Y-Fabric

X-Fabric

WANSharedDriver

SWAN

SWAN

X25AM Line-Handler Process

NAM

Expand-over-X.25Line-Handler

Process


LANAdapter

LANAdapter


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 more information on configuring X25AM line-handler processes, see the X25AM Configuration and Management Manual.

QIO Subsystem




The WAN shared driver is a set of library procedures that is bound with each input-output 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.



The NonStop TCP/IP subsystem provides TCP/IP data communications connectivity. NonStop TCP/IP processes are used by LAN adapters and SWAN concentrators. The NonStop TCP/IP processes that support the adapter and SWAN concentrators are preconfigured and started during the system load sequence.

For more information on the NonStop TCP/IP and the NonStop TCP/IPv6 subsystems, see the TCP/IP Configuration and Management Manual and the TCP/IPv6 Configuration and Management Manual.

For more information on the LAN adapters, see the LAN 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.


Configuring Expand-Over-X.25 Lines 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 more information on the SLSA subsystem and LAN adapters, see the LAN Configuration and Management Manual.


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 more information on the SWAN concentrator, see the WAN Subsystem Configuration and Management Manual.


Configuring Expand-Over-X.25 Lines Topology Considerations

Topology ConsiderationsAn 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 multi-CPU 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.

Figure 10-2. Expand-Over-X.25 Line-Handler Process Topology

VST043.vsd

PSDN

Node \A

CPU 1 CPU 2

LH

CPU 0

LH

LH

Node \B

CPU 0 CPU 1

LH LH

Node \C

CPU 0

LH

CPU 2

LH

LH

Key

Configured Path

Multi-CPUPath

Single-Line Path

Multiline Path


Configuring Expand-Over-X.25 Lines Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see Required Hardware and Software on page 10-2 for details), configuring and starting a single-line Expand-over-X.25 line-handler process involves these 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 Line-Handler Process

SCF interface to the WAN subsystem

Step 4: Create the Expand-Over-X.25 Line-Handler Process


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. For more information, see:

• X25AM Configuration and Management Manual for X25AM subsystem SCF commands




Configuring Expand-Over-X.25 Lines Step 1: Add a NAM Subdevice to the X25AM Line

Step 1: Add a NAM Subdevice to the X25AM Line

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, this 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

For more information, see the X25AM Configuration and Management Manual.

Considerations

These 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 LineBefore 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, this command starts an X25AM line-handler process named $X2501:

-> START LINE $x2501

Note. This 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, see the WAN Subsystem Configuration and Management Manual.


Configuring Expand-Over-X.25 Lines Step 3: Create a Profile for the Expand-Over-X.25 Line-Handler Process

Step 3: Create a Profile for the Expand-Over-X.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, see the WAN Subsystem Configuration and Management Manual.

This subsection describes how to create a profile using PEXQSNAM.

ADD Profile Command

To create a profile from the PEXQSNAM profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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.


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-over-NAM 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.

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 13, Configuring Multi-Line Paths.



Configuring Expand-Over-X.25 Lines Example

Example

In this example, a profile named SLHX25 is created for a single-line Expand-over-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

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.

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:

$ZZWAN.#device_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.

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 13, Configuring Multi-Line Paths.

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 ] ] ...


Configuring Expand-Over-X.25 Lines ADD DEVICE Command

CPU cpunumber


ALTCPU altcpunumber


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 single-line Expand-over-X.25 line-handler processes.

RSIZE rsize


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


Modifier names in the PEXQSNAM profile are listed in Profile Modifiers on page 10-13.


Configuring Expand-Over-X.25 Lines Considerations

modifier_value


Default values and ranges of values for modifiers in the PEXQSNAM profile are described in Profile Modifiers on page 10-13.

Considerations



Examples

In this 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


-> 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


Configuring Expand-Over-X.25 Lines Step 5: Start the Expand-Over-X.25 Line-Handler Process

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:

$ZZWAN.device_name

specifies, via the WAN subsystem, the device name of the Expand-over-X.25 line-handler process.


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:

device_name

is the device name of the Expand-over-X.25 line-handler process.





Configuring Expand-Over-X.25 Lines Profile Modifiers

Profile ModifiersThis 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.


Recommended modifiers are modifiers that should be used to obtain optimum performance and efficiency. This modifier is recommended for Expand-over-X.25 line-handler processes:

L4TIMEOUTn

Default: 2000 (20 seconds) Units: 0.01 seconds Range: 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 cause excessive packet charges, you should set L4TIMEOUT to a value in excess of the maximum anticipated response time on a loaded link.


These modifiers are provided in the PEXQSNAM profile to enable you to configure special features:


window feature

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 13, Configuring Multi-Line Paths.

Note. The Expand End-to-End protocol is explained in Path Function of the Expand Subsystem on page 17-13.


Configuring Expand-Over-X.25 Lines X25AM Line-Handler Process Modifiers



X25AM Line-Handler Process Modifiers

You might need to set this 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: 2 Units: Packets Range: 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.

PEXQSNAM Modifiers

The disk file $SYSTEM.SYSnn.PEXQSNAM defines modifiers for Expand-over-X.25 line-handler processes.


Note. Some X.25 networks limit the size of L3WINDOW. Consult your vendor for more information.

Table 10-1. PEXQSNAM Modifiers for Expand-over-X.25 Lines (page 1 of 3)




ASSOCIATEDEV1 Any 8-character string

ASSOCIATESUBDEV1 Any 8-character string

COMPRESS_OFF

COMPRESS_ON 3


Configuring Expand-Over-X.25 Lines PEXQSNAM Modifiers


CONNECTTYPE_PASSIVE




L4CONGCTRL_OFF 3 ON or OFF

L4CONGCTRL_ON


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3







NEXTSYS2 255 0 through 254










STARTUP_OFF 3

STARTUP_ON

SUPERPATH_OFF 3

SUPERPATH_ON

TIMERINACTIVITY 900 0 through 32767





Configuring Expand-Over-X.25 Lines PEXQSNAM Modifiers



1. This is a required modifier. It has no default value.





11Configuring 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 13, Configuring Multi-Line Paths.


Configuring Expand-Over-SNA Lines Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the Expand-over-SNA line-handler process to provide Expand-over-SNA connectivity. These components are illustrated in Figure 11-1 and are explained in these subsections.

Figure 11-1. Expand-Over-SNA Line-Handler Process Components

VST005

Processor


TCP/IPProcess


Y-Fabric

X-Fabric

WANSharedDriver

SWAN

SWAN

SNAX/APNLine-Handler

Process

NAM

Expand-over-SNA Line-

Handler Process


LANAdapter

LANAdapter


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 more information on creating SNAX/APN line-handler processes, see the WAN Subsystem Configuration and Management Manual. For more information on adding SNAX/APN lines and LUs, see the SNAX/XF and SNAX/APN Configuration and Management Manual.

QIO Subsystem


For more information on the QIO subsystem, see the QIO Configuration and Management Manual. For more information on how the WAN subsystem uses QIO, see the WAN Subsystem Configuration and Management Manual.


The WAN shared driver is a set of library procedures that is bound with each input-output 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.



Configuring Expand-Over-SNA Lines NonStop TCP/IP Process


The NonStop TCP/IP subsystem provides TCP/IP data communications connectivity. NonStop TCP/IP processes are used by the LAN adapters and SWAN concentrators. The NonStop TCP/IP processes that support these adapters and SWAN concentrators are preconfigured and started during the system load sequence.

For more information on the NonStop TCP/IP and NonStop TCP/IPv6 subsystems, see the TCP/IPv6 Configuration and Management Manual and the TCP/IPv6 Configuration and Management Manual.

For more information on LAN adapters, see the LAN Configuration and Management Manual.


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.



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 more information on configuring the SWAN concentrator, see the WAN Subsystem Configuration and Management Manual.


Configuring Expand-Over-SNA Lines Topology Considerations

Topology ConsiderationsAn 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 multi-CPU 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.

Figure 11-2. Expand-Over-SNA Line-Handler Process Topology

VST044.vsd

SNA Network

Node \A

CPU 1 CPU 2

LH

CPU 0

LH

LH

Node \B

CPU 0 CPU 1

LH LH

Node \C

CPU 0

LH

CPU 2

LH

LH

Key

Configured Path

Multi-CPUPath

Single-Line Path

Multiline Path


Configuring Expand-Over-SNA Lines Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see Required Hardware and Software on page 11-2 for details), configuring and starting a single-line Expand-over-SNA line-handler process involves these 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 Line-Handler Process


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. For more information, see:

• SNAX/XF and SNAX/APN Configuration and Management Manual for SNAX/APN subsystem commands




Configuring Expand-Over-SNA Lines Step 1: Add the SNAX/APN Line

Step 1: Add the SNAX/APN Line

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, this 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, see 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.

Note. These 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 more information on creating SNAX/APN line-handler processes, see the WAN Subsystem Configuration and Management Manual.


Configuring Expand-Over-SNA Lines Step 2: Add the LUs for the SNAX/APN Line

Step 2: Add the LUs for the SNAX/APN LineYou 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, this 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, this 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, this 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

For details about configuring LUs and PUs, and SCF ADD LU and ADD PU command attributes, see the SNAX/XF and SNAX/APN Configuration and Management Manual.

Considerations

This 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.


Configuring Expand-Over-SNA Lines Example

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.

Figure 11-3. SNAX/APN Line Configuration Example

VST050.vsd

SNA Network

SWAN

SWAN

System \A

System \B

ExpandLine-Handler

Process


Process($SNAPA)


Process($SNASB)

ExpandLine-Handler

Process

SCF Commands for System \A

ADD LINE $SNAPA, RECSIZE 524, MAXPUS 1, MAXLUS 30, STATION PRIMARY, MAXLOCALLUS 10, POLLINT 0.01ADD LU $SNAPA.#LLUA, TYPE (14,21)

, SNANAME LUA, PROTOCOL NAM

, DLUNAME #RLUA, RSPTYPE ERADD PU $SNAPA.#RPUA, TYPE (13,21), ADDRESS %HC1, RECSIZE 521, MAXLUS 30

ADD LU $SNAPA.#RLUA, SNANAME LUB, PUNAME #RPUA

SCF Commands for System \B

ADD LINE $SNASB, RECSIZE 524, MAXPUS 1, MAXLUS 30, STATION SECONDARY, MAXLOCALLUS 10ADD LU $SNASB.#LLUB, TYPE (14,21), SNANAME LUB, PROTOCOL NAM, DLUNAME #RLUB, RSPTYPE ERADD PU $SNASB.#RPUB, TYPE (13,21), ADDRESS %HC1, RECSIZE 521, MAXLUS 30ADD LU $SNASB.#RLUB

, SNANAME LUA, PUNAME #RPUB

Local LU SNANAMEand remote LU SNANAMEmust match

Local LU DLUNAMEand remote LUsubdevicename must match


Configuring Expand-Over-SNA Lines Step 3: Start the SNAX/APN Line

Step 3: Start the SNAX/APN LineBefore 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. This 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, see the SNAX/XF and SNAX/APN Configuration and Management Manual.

Step 4: Create a Profile for the Expand-Over-SNA 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, see the WAN Subsystem Configuration and Management Manual.

This subsection shows you how to create a profile using PEXQSNAM.

ADD Profile Command

To create a profile from the PEXQSNAM profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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.


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-over-NAM line-handler processes.

Note. Different profiles are provided for Expand-over-SNA lines that are part of a multi-line path; these profiles are described in Section 13, Configuring Multi-Line Paths.



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-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 PEXQSNAM profile are described in Profile Modifiers on page 11-15.

Example

In this example, a profile named SLHSNA is created for a single-line Expand-over-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.

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:

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 13, Configuring Multi-Line Paths.

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 ] ] ...


Configuring Expand-Over-SNA Lines ADD DEVICE Command

$ZZWAN.#device_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


ALTCPU altcpunumber


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 single-line Expand-over-SNA line-handler processes.

RSIZE rsize


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.


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


Modifier names in the PEXQSNAM profile are listed in Profile Modifiers on page 11-15.

modifier_value


Default values and ranges of values for modifiers in the PEXQSNAM profile are described in Profile Modifiers on page 11-15.

Considerations



Examples

In this 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. (For the commands used to configure #LLUA and $SNAPA, see Figure 11-3 on page 11-9.) 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


Configuring Expand-Over-SNA Lines Step 6: Start the Expand-Over-SNA Line-Handler Process


-> 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:

$ZZWAN.device_name

specifies, via the WAN subsystem, the device name of the Expand-over-SNA line-handler process.


Step 7: Start the Expand-Over-SNA LineTo start an Expand-over-SNA line, use the Expand subsystem SCF START LINE command. The command syntax is:

device_name

is the device name of the Expand-over-SNA line-handler process.





Configuring Expand-Over-SNA Lines Profile Modifiers

Profile ModifiersThis 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.


Recommended modifiers are modifiers that should be used to obtain optimum performance and efficiency. This modifier is recommended for Expand-over-SNA line-handler processes:

L4TIMEOUT n

Default: 2000 (20 seconds) Units: 0.01 seconds Range: 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 cause excessive packet charges, you should set L4TIMEOUT to a value in excess of the maximum anticipated response time on a loaded link.


These modifiers are provided in the PEXQSNAM profile to enable you to configure special features:


window feature

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 13, Configuring Multi-Line Paths.

Note. The Expand End-to-End protocol is explained in Path Function of the Expand Subsystem on page 17-13.


Configuring Expand-Over-SNA Lines PEXQSNAM Modifiers



PEXQSNAM Modifiers

The disk file $SYSTEM.SYSnn.PEXQSNAM defines modifiers for Expand-over-SNA line-handler processes.


Table 11-1. PEXQSNAM Modifiers for Expand-over-SNA Lines (page 1 of 2)




ASSOCIATEDEV1 Any 8-character string


COMPRESS_OFF

COMPRESS_ON 3


CONNECTTYPE_PASSIVE




L4CONGCTRL_OFF 3

L4CONGCTRL_ON


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3



















STARTUP_OFF 3

STARTUP_ON

SUPERPATH_OFF 3

SUPERPATH_ON

TIMERINACTIVITY 900 0 through 32767




1. This is a required modifier. It has no default value.


Table 11-1. PEXQSNAM Modifiers for Expand-over-SNA Lines (page 2 of 2)



12Configuring 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).



Configuring Expand-Over-ServerNet Lines Required Hardware and Software

Required Hardware and SoftwareSeveral hardware and software components are required in addition to the Expand-over-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 depicts a local node consisting of three processors: Processor 1 is running an application, Processor 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 processor switches, 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.

Figure 12-1. Expand-Over-ServerNet Connectivity Components


X Fabric

Expand/ServerNet

Line-Handler

Guardian

Message System

$ZZSCLApplication

Remote Node

Processor 1 Processor 2 Processor 3Local Node

Y Fabric

Cluster Switch

Processor ...

VST047.vsd

Cluster Switch


Configuring Expand-Over-ServerNet Lines Expand Manager Process ($ZEXP)

The components shown for this communications request and other components necessary for Expand-over-ServerNet lines are described in subsequent sections.

Expand Manager Process ($ZEXP)

The Expand subsystem requires that the Expand manager process ($ZEXP) be running during network operation. For more information on running this process, see Task 2: Start the Expand Manager Process on page 1-3.

External System Area Network Manager (SANMAN)

The External System Area Network Manager (SANMAN) is a new process pair that runs in every Integrity NonStop NS-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 runs 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.

MSGMON is a persistent process. After 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.

Network Access Method (NAM)

NAM is a pair of message system dialects that allow use of another process, such as X.25 or SNAX, as an Expand communications medium. NAM contains connection establishment, data transfer, and disconnection phases. For more information, see Expand-to-NAM Interface on page 17-49.


Note. MSGMON is compatible only with G06.09 and later RVUs of the NonStop operating system.


Configuring Expand-Over-ServerNet Lines Network Control Process ($NCP)

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 on the cluster switch, see 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:

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 can be absent for a short period, until the


Table 12-1. Profile Products Needed for Compatibility With Other Expand Lines

Profile Line Types Supported

Expand/ServerNet (T0509H0x) Expand-over-ServerNet Required for everyone

Expand/SWANgroup (T0532H0x) X.25 NETDIRECT NETSATELLITE IP ATM

Required for new users

Expand/FastPipe (T0533H0x) IP ATM

Required for new users



Configuring Expand-Over-ServerNet Lines ServerNet Cluster Product

persistence manager starts a new ServerNet cluster monitor process. Because 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 more information on configuring $ZZSCL, see the ServerNet Cluster Manual.

ServerNet Cluster Product

ServerNet clusters enable multiple Integrity NonStop NS-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, see 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 more information on the WAN subsystem, see the WAN Subsystem Configuration and Management Manual.

X and Y Fabrics

X and Y fabrics are a collection of connected routers and ServerNet links that, together, provide an interconnection for Integrity NonStop NS-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.



Configuring Expand-Over-ServerNet Lines Topology Considerations

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

VST048.vsd

\NODE4

\NODE3

\NODE2

Key

Configured Single-Line Path

\NODE1

$X252

$LINE2

$LINE3

$LINE4

$LINE1

$LINE2

$LINE3

$LINE1

$LINE4

$LINE3

$LINE4

$LINE1

$LINE2

X-Fabric

Y-Fabric


Configuring Expand-Over-ServerNet Lines Summary of Configuration Steps

Summary of Configuration StepsAfter all hardware and software requirements have been met (see Required Hardware and Software on page 12-2 for details), configuring Expand-over-ServerNet connections involves these steps:

Configuring a ServerNet Node

To prepare an Integrity NonStop NS-series server to become a node in a ServerNet cluster, see the guided procedure online help, which:

• Creates a ServerNet cluster for the first time

• Adds a node to an already configured ServerNet cluster

Step Tool Used

Step 1: Create a Profile for the Expand-Over-ServerNet Line-Handler Process


Step 2: Create a Device for the Expand-Over-ServerNet Line-Handler Process


Step 3: Start the Expand-Over-ServerNet Line-Handler Processes


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. For more information, see:





Configuring Expand-Over-ServerNet Lines Step 1: Create a Profile for the Expand-Over-ServerNet Line-Handler Process

Step 1: Create a Profile for the Expand-Over-ServerNet 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, see the WAN Subsystem Configuration and Management Manual.

This subsection shows you how to create a profile using PEXPSSN.

ADD Profile Command

To create a profile from the PEXPSSN profile template, use the WAN subsystem SCF ADD PROFILE command. The command syntax is:

$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-ServerNet line-handler processes in Step 2: Create a Device for the Expand-Over-ServerNet Line-Handler Process.


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-over-ServerNet 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.



Configuring Expand-Over-ServerNet Lines Example

Example

In this example, a profile named PEXPSSN is created for an Expand-over-ServerNet 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

Step 2: Create a Device for the Expand-Over-ServerNet 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 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:

$ZZWAN.#device_name

specifies, via the WAN subsystem, the device name of the Expand-over-ServerNet line-handler process to add.




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.

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 ] ] ...


Configuring Expand-Over-ServerNet Lines ADD DEVICE Command

CPU cpunumber

indicates the processor where this Expand-over-ServerNet line-handler process will normally run.

ALTCPU altcpunumber

indicates the processor where the backup Expand-over-ServerNet line-handler process will normally run.

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


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.

Note. HP recommends that you use the Notation Conventions to configure line handlers, to avoid configuring them in processors 0 and 1. For more information, see Considerations on page 12-11.


Configuring Expand-Over-ServerNet Lines Considerations

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.

Considerations



• Here are recommended configuration guidelines for configuring Expand-over-ServerNet line handlers. (If you use the Notation Conventions, 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 might fail in the presence of hardware faults is higher.

Example

In this example, a device named #SC001 is created for an Expand-over-ServerNet 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


Configuring Expand-Over-ServerNet Lines Step 3: Start the Expand-Over-ServerNet Line-Handler Processes

Step 3: Start the Expand-Over-ServerNet Line-Handler 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:

$ZZWAN.device_name

specifies, via the WAN subsystem, the device name of the Expand-over-ServerNet line-handler process.


Example

In this example, the device named #SC001 is started.

-> START DEVICE $ZZWAN.#SC001

Step 4: Start the Expand-Over-ServerNet Lines

To start an Expand-over-ServerNet line, use the Expand subsystem SCF command START LINE. The command syntax is:

device_name

is the device name of the Expand-over-ServerNet line-handler process.

The successful completion of this command leaves the line in the STARTED state. To check the status of the line, enter this SCF command:


Note. Do not perform this step unless you have already physically connected the Integrity NonStop NS-series server to the ServerNet cluster. Connecting a Integrity NonStop NS-series server to a ServerNet cluster is described in the ServerNet Cluster Manual.


Note. Wait about five seconds after starting the device before you start the line.

STATUS LINE $device_name


Configuring Expand-Over-ServerNet Lines Profile Modifiers

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 ModifiersThis 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.


The L4CONGCTRL_ON modifier is provided in the PEXPSSN profile to enable you to configure the congestion control feature. The L4CWNDCLAMP modifier is provided in the PEXPSSN profile to enable you to configure the congestion control transmit window feature. For configuration considerations for congestion control feature, see Section 17, Subsystem Description. For more information on the advantages and disadvantages of congestion control feature, see Section 3, Planning a Network Design. The L4CONGCTRL_ON and L4CWNDCLAMP modifiers are described in detail in Section 16, Expand Modifiers.

PEXPSSN Modifiers

The disk file $SYSTEM.SYSnn.PEXPSSN defines modifiers for Expand-over-ServerNet line-handler processes.


Note. The multipacket frame and variable packet size features are not supported on Expand-over-ServerNet connections.

Table 12-2. PEXPSSN Modifiers for Expand-over-ServerNet Lines (page 1 of 2)



AFTERMAXRETRIES_PASSIVE 3ASSOCIATEDEV1 $ZZSCL Any 8-character string

COMPRESS_OFF

COMPRESS_ON 3CONNECTTYPE_ACTIVEANDPASSIVE 3CONNECTTYPE_PASSIVE



Configuring Expand-Over-ServerNet Lines PEXPSSN Modifiers




L4CONGCTRL_OFF 3L4CONGCTRL_ON


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3L4RETRIES 3 3 through 255
















STARTUP_OFF 3STARTUP_ON

SUPERPATH_OFF OFF






Table 12-2. PEXPSSN Modifiers for Expand-over-ServerNet Lines (page 2 of 2)



13 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.

Configuration OverviewA 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 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.

Figure 13-1 shows the logical devices required for a multi-line path that consists of four lines.

Note. For more information on the benefits and disadvantages of configuring multi-line paths, see Section 3, Planning a Network Design.

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 17-9.

Figure 13-1. Logical Devices for a Multi-Line Path

VST039.vsd

Line Logical Devices $PATH

$LINE1 $LINE2 $LINE3 $LINE4

Path Logical Device


Configuring Multi-Line Paths Configuration Considerations

Configuration Considerations

Consider these when configuring 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 Expand-over-IP lines with other line types.

• 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 on the multi-CPU paths and Expand-over-IP, see When to Use a Multi-CPU Path on page 3-9.

• 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. For more information on this recommended setting, see PATHTF n on page 16-20.


Configuring Multi-Line Paths Summary of Configuration Steps

Summary of Configuration StepsConfiguring and starting a multi-line path involves these steps:

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, see 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:

$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

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

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 multi-line paths; it is not meant to show the complete syntax of the SCF commands described. For more information, see:



ADD PROFILE $ZZWAN.#profile_name , FILE $SYSTEM.SYSnn.PEXPPATH [, modifier_keyword [ modifier_value ] ] ...


Configuring Multi-Line Paths Step 2: Create a Profile for Each Line Type

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.

modifier_keyword

is the name of a modifier in profile_name. Modifier names in the PEXPPATH profile are listed in PEXPPATH Modifiers on page 13-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 PEXPPATH profile are described in PEXPPATH Modifiers on page 13-16.

Step 2: Create a Profile for Each Line TypeYou 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 Expand-over-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, see 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:

$ZZWAN.profile_name

ADD PROFILE $ZZWAN.#profile_name , FILE $SYSTEM.SYSnn.diskfile_name [, modifier_keyword [ modifier_value ] ] ...


Configuring Multi-Line Paths ADD PROFILE Command

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 13-1 lists the disk filenames that are provided for line-logical devices. These disk files are installed in $SYSTEM.SYSnn.

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 13-18.

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 line-logical device profiles are described in Line-Logical Device Modifiers on page 13-18.

Table 13-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


Configuring Multi-Line Paths Step 3: Create a Path-Logical Device

Step 3: Create a Path-Logical DeviceYou 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:

$ZZWAN.#path_name

specifies, via the WAN subsystem, the name of the path-logical device you want to add.


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.


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 run.

ALTCPU altcpunumber

is the processor number where the backup path-logical device will normally run.

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 path-logical devices.

RSIZE 0

The RSIZE value must be set to 0.

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 ] ] ...


Configuring Multi-Line Paths 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 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 13-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 path-logical device.

Default values and ranges of values for modifiers in PEXPPATH are described in PEXPPATH Modifiers on page 13-16.

Considerations



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.


Configuring Multi-Line Paths Step 4: Create the Line-Logical Devices

Step 4: Create the Line-Logical DevicesYou 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:

$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 line-logical device. This value must be the same as that of the associated path device.


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 run.

ALTCPU altcpunumber

is the processor number where the backup line-logical device will normally run.

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 ] ] ...


Configuring Multi-Line Paths ADD DEVICE Command

TYPE devsubtype

is the device subtype for this line-logical device. The device subtypes for line-logical devices are listed in Table 13-2.

RSIZE rsize


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.

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-5. For more information on adding SWAN concentrators, see 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. For more information on identifying CLIP numbers, see Step 1: Find an Available WAN Line on page 7-5.

Table 13-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



LINE linenum

is the number of an available WAN line on the CLIP specified by clipnum. For more information on identifying line numbers, see Step 1: Find an Available WAN Line on page 7-5. 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 more information on adding Ethernet paths, see 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 13-18.

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 13-18.

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-17. 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 line-handler process’ SRCIPPORT modifier. Determining port numbers is described in Step 2 (A): Identify an Available UDP Port Number on page 8-17. 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 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use on page 8-11. 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.

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 (B): Select a Process and SUBNET for NonStop TCP/IPv6 Use on page 8-11. 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.

ATMSEL selector_byte

is a hexadecimal selector byte for the ATM line used by this Expand-over-ATM line-handler process. Obtaining selector bytes is described in Obtaining Selector Bytes for the Local and Remote ATM Lines on page 9-6.


DESTATMADDR (ISONSAP:%Hatm_address)

is 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. For example:

(ISONSAP:%H47000580FFE1000000F21A29EB0000000001B300)

Identifying ATM addresses is described in Identifying the ATM Address Configured for the Remote ATM Line on page 9-7.



Configuring Multi-Line Paths Considerations

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).


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:

$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.



Configuring Multi-Line Paths Step 6: Start the Lines

Step 6: Start the LinesTo start all the lines in the multi-line path, use the Expand subsystem SCF START PATH command. The command syntax is:

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:

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.

START PATH $device_name



Configuring Multi-Line Paths Configuration Example

Configuration ExampleThis example shows a multi-line path with one direct-connect line and one Expand-over-SNA line. Figure 13-2 illustrates the configuration of this example.

These command examples show the WAN subsystem SCF commands used to configure the multi-line path shown in Figure 13-2.

• This 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

• This 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

• This 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

• This 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

Figure 13-2. Multi-Line Configuration Example

Note. The SWAN concentrator used by the SNAX/APN process $SNA1 is shown as a transparent box because it is not configured in this command example.

VST046.vsd

$PATH

$LINE1

$LINE2 $SNA1MULTI

MULTI

ASSOCIATEDEV

SWAN003A

SWANxxxxx


Configuring Multi-Line Paths Path-Logical Device Modifiers

• This SCF ADD DEVICE command creates a line-logical device named $LINE1 for the direct-connect line. Note 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

• This SCF ADD DEVICE command creates a line-logical device named $LINE2 for the Expand-over-SNA line. Note 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 ModifiersThis subsection describes the modifiers provided to configure special features and the default values and ranges for the modifiers contained in the PEXPPATH profile.


These 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• L4CWNDCLAMP for the configuration of the congestion control transmit window

feature



PEXPPATH Modifiers

The disk file $SYSTEM.SYSnn.PEXPPATH defines modifiers for path-logical devices. Table 13-3 on page 13-17 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, see Section 16, Expand Modifiers.


Configuring Multi-Line Paths PEXPPATH Modifiers

Table 13-3. PEXPPATH Modifiers


COMPRESS_OFF

COMPRESS_ON 3L4CONGCTRL_OFF 3L4CONGCTRL_ON


L4EXTPACKETS_OFF

L4EXTPACKETS_ON 3L4RETRIES 3 3 through 255








PATHTF 0 (not set) 0 through 186

SUPERPATH_OFF 3SUPERPATH_ON



Configuring Multi-Line Paths Line-Logical Device Modifiers

Line-Logical Device ModifiersThis 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, see Section 16, Expand Modifiers.

X25AM Process Modifiers

You might need to set this 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.

L3WINDOW n

Default: 2 Units: Packets Range: 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.

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 13-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.

Note. There are no required modifiers for direct-connect and satellite-connect lines in a multi-line path.

Note. Some X.25 networks limit the size of L3WINDOW. Consult your vendor for more information.

Table 13-4. PEXQMSWN and PEXQMSAT Modifiers (page 1 of 2)


CLOCKMODE_DCE 3CLOCKMODE_DTE

CLOCKSPEED_600

CLOCKSPEED_1200

CLOCKSPEED_2400


Configuring Multi-Line Paths PEXQMSWN and PEXQMSAT Modifiers

CLOCKSPEED_4800

CLOCKSPEED_9600

CLOCKSPEED_19200 3CLOCKSPEED_38400

CLOCKSPEED_56000

CLOCKSPEED_115200

DELAY 10 0 through 511

DOWNIFBADQUALITY_ON

DOWNIFBADQUALITY_OFF 3FLAGFILL_OFF

FLAGFILL_ON 3FRAMESIZE 132 64 through 2047

INTERFACE_RS232 3INTERFACE_RS422


L2DISCARDONRESET_ON 3L2RETRIES 10 1 through 255




PROGRAM $SYSTEM.CSSnn. C1097P00 (direct-connect) $SYSTEM.CSSnn. C1098P00 (satellite-connect)







TXWINDOW 7 (direct-connect) 18 (satellite-connect)

2 through 61

Table 13-4. PEXQMSWN and PEXQMSAT Modifiers (page 2 of 2)



Configuring Multi-Line Paths PEXQMNAM Modifiers

PEXQMNAM Modifiers

The disk file $SYSTEM.SYSnn.PEXQMNAM defines modifiers for Expand-over-NAM lines in multi-line paths. Table 13-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 13-5. PEXQMNAM Modifiers



AFTERMAXRETRIES_PASSIVE 3ASSOCIATEDEV1 Any 8-character string


CONNECTTYPE_ACTIVEANDPASSIVE 3CONNECTTYPE_PASSIVE












1. This is required modifier. It has no default value.


Configuring Multi-Line Paths PEXQMIP Modifiers

PEXQMIP Modifiers

The disk file $SYSTEM.SYSnn.PEXQMIP defines modifiers for Expand-over-IP lines in multi-line paths. Table 13-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 13-6. PEXQMIP Modifiers (page 1 of 2)



AFTERMAXRETRIES_PASSIVE 3ASSOCIATEDEV1 None Any 8-character string

CONNECTTYPE_ACTIVEANDPASSIVE 3CONNECTTYPE_PASSIVE

DESTIPADDR2 0.0.0.1 Any 36-character string

DESTIPPORT1 1024 0 through 65534

DOWNIFBADQUALITY_ON

DOWNIFBADQUALITY_OFF 3EXTMEMSIZE 2048 0 through 32767


IPVER_IPV4 3IPVER_IPV6











SRCIPADDR2 0.0.0.1 Any 36-character string

SRCIPPORT1 1024 0 through 65534




Configuring Multi-Line Paths PEXQMATM Modifiers

PEXQMATM Modifiers

The disk file $SYSTEM.SYSnn.PEXQMATM defines modifiers for Expand-over-ATM lines in multi-line paths. Table 13-7 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.

V6DESTIPADDR 0000:0000:0000:0000:0000:0000:0000:0000


V6SRCIPADDR 0000:0000:0000:0000:0000:0000:0000:0000



2. This is a required modifier. For IP address syntax, see the TCP/IP Configuration and Management Manual, TCP/IP (Parallel Library) Configuration and Management Manual, or TCP/IPv6 Configuration and Management Manual.

Table 13-7. PEXQMATM Modifiers (page 1 of 2)


AFTERMAXRETRIES_DOWN OFF ON or OFF

AFTERMAXRETRIES_PASSIVE 3 ON or OFF


CONNECTTYPE_ACTIVEANDPASSIVE 3 ON or OFF

ATMSEL2 %H80 0 through %HFF

CALLTYPE_PVC3 3CALLTYPE_SVC2

CONNECTTYPE_PASSIVE

DESTATMADDR2 (ISONSAP: %H00...)

Any valid ISO NSAP ATM address

DOWNIFBADQUALITY_ON

DOWNIFBADQUALITY_OFF 3FRAMESIZE 132 64 through 2047





PVCNAME3 None Any 8-character string

Table 13-6. PEXQMIP Modifiers (page 2 of 2)












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.

Table 13-7. PEXQMATM Modifiers (page 2 of 2)




Part III consists of these sections, which describe the Subsystem Control Facility (SCF) interface to the Expand subsystem:

Section 14 Subsystem Control Facility (SCF) Commands

Section 15 Tracing


14Subsystem Control Facility (SCF) Commands

This section describes the Subsystem Control Facility (SCF) interface to the Expand subsystem and provides SCF command syntax. For general information about running SCF, see the SCF Reference Manual for H-Series RVUs.

Topics described in this section include:

• Overview of the Expand Subsystem SCF Interface on page 14-2• SCF and the WAN Subsystem on page 14-7• SCF and the SLSA Subsystem on page 14-8• ABORT Command on page 14-8• ACTIVATE Command on page 14-9• ALTER Command on page 14-10• ALTER DEVICE Command on page 14-10• ALTER PATH Command on page 14-11• ALTER LINE Command on page 14-12• ALTER PROCESS Command on page 14-21• DELETE ENTRY Command on page 14-23• INFO Command on page 14-24• INFO PATH Command on page 14-25• INFO LINE Command on page 14-31• INFO PROCESS Command on page 14-50• PRIMARY PROCESS Command on page 14-70• PROBE PROCESS Command on page 14-71• START Command on page 14-73• STATS Command on page 14-74• STATS PATH Command on page 14-74• STATS PATH NODE Command on page 14-81• STATS PROCESS Command on page 14-97• STATUS Command on page 14-101• STATUS PATH Command on page 14-101• STATUS LINE Command on page 14-103• STOP Command on page 14-111• TRACE Command on page 14-112• VERSION Command on page 14-117• VERSION PROCESS Command on page 14-118


Subsystem Control Facility (SCF) Commands Overview of the Expand Subsystem SCF Interface

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 these 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 14-1 shows the Expand subsystem objects supported by SCF and their hierarchical order.

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:

Figure 14-1. Expand Subsystem Object Hierarchy

VST051.vsd

ENTRY

LINE

PROCESS PATH


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.

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.

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, and X.25 Connections

Expand-over-NAM, Expand-over-IP, Expand-over-ATM, Expand-over-ServerNet, and Expand-over-X.25 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.

Note. For more information on how the Expand subsystem relates to the OSI Reference Model, see Expand Subsystem and the OSI Reference Model on page 17-9.

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.


Subsystem Control Facility (SCF) Commands Object States

These are some typical device names:

PROCESS Object

The PROCESS object type might see 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.

These states are recognized by the Expand subsystem:

$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

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.


Subsystem Control Facility (SCF) Commands SCF Commands and Objects

SCF Commands and Objects

Table 14-1 lists the SCF commands and objects that are applicable to the Expand subsystem.

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 these 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

Table 14-1. Expand Commands and Object Types

Object Types

CommandPROCESS

(Line Handler)PROCESS

($NCP) ENTRY PATH LINE

ABORT X X

ACTIVATE X

ALTER X X X

DELETE X

INFO X X X

PRIMARY X X

PROBE X

START X X

STATS X X X

STATUS X X

STOP X X

TRACE X X X

VERSION X X


Subsystem Control Facility (SCF) Commands Wild-Card Support

Table 14-2 lists the sensitive and nonsensitive Expand SCF commands.

Wild-Card Support

Object name templates (wild cards) are supported for most WAN subsystem SCF commands as described in the SCF Reference Manual for H-Series RVUs.

Time Values

The variable time is used for attributes that require a time interval to be specified. The syntax of time is

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.

Table 14-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

HH:MM:SS.hh


Subsystem Control Facility (SCF) Commands SCF and the WAN Subsystem

SCF and the WAN SubsystemOn Integrity NonStop NS-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.

This 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 line-handler 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 these 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 line-handler process before you change modifier values using the ALTER DEVICE command.

• The SCF interface to the WAN subsystem handles 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 line-handler process in the primary and backup processors. Use the Expand subsystem START PATH or START LINE command to start path and line functions after the Expand line-handler process is started.


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, see Appendix B, Expand and WAN SCF Comparison.

SCF and the SLSA SubsystemFor more information on the management of the ATMSAP connection object by the SCF ABORT, ADD, ALTER, DELETE, INFO, NAMES, START, STATS, STATUS, and STOP commands, see the LAN Configuration and Management Manual.

ABORT CommandThe 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:

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.

ABORT { PATH path-name | LINE line-name }


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:

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 CommandThe 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:

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

This SCF command initiates the immediate rebalance of the multi-CPU path to the system named \NODEA:

-> ACTIVATE PROCESS $NCP, REBAL \NODEA

ACTIVATE PROCESS $NCP, REBAL [ system-name ]


Subsystem Control Facility (SCF) Commands ALTER Command

ALTER CommandThe 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:

ALTER DEVICE CommandThe 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. For more information on this command, see the WAN Subsystem Configuration and Management Manual.

The ALTER DEVICE command has this syntax (you must specify one or more attributes):

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 this commands to SCF:

1-> abort line $lh01 2-> stop device $zzwan.#lh01 3-> alter device $zzwan.#lh01, highpin off 4-> start device $zzwan.#lh01 5-> start line $lh01

Note that in Step 1, you must stop the line to stop the device, and in Step 2, you must stop the device to alter the device.

ALTER { PROCESS $NCP | PATH path-name | LINE line-name }

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 ) ]


Subsystem Control Facility (SCF) Commands ALTER PATH Command

ALTER PATH CommandThe ALTER PATH command is described below. The PATH object type takes this form:

PATH path-name attribute-spec [, attribute-spec ] ...

where path-name is the device name of a path and attribute-spec is one of this attribute name and value combinations:

Table 14-3 lists the path attributes that have corresponding profile modifiers.

For more information on each path attribute, see the description of the corresponding profile modifier in Section 16, Expand Modifiers.

[ COMPRESS { ON | OFF } ] [ L4CONGCTRL { ON | OFF } ][ L4CWNDCLAMP integer ] [ L4EXTPACKETS { ON | OFF } ] [ L4RETRIES integer ] [ L4SENDWINDOW n] [ L4TIMEOUT time ] [ NEXTSYS system-number ] [ OSSPACE integer ] [ OSTIMEOUT time ] [ PATHBLOCKBYTES integer ] [ PATHPACKETBYTES integer ][ SUPERPATH { ON | OFF } ]

Table 14-3. ALTER PATH Attributes and Corresponding Profile Modifiers

SCF Attribute Profile Modifier

COMPRESS COMPRESS_OFF/COMPRESS_ON

L4CONGCTRL L4CONGCTRL_OFF/L4CONGCTRL_ON

L4CWNDCLAMP L4CWNDCLAMP n

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


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:

-> PATH ( path-name , path-name [ , path-name ] ... )

Examples

This 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

This 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 CommandThe ALTER LINE command is described below. The LINE object type takes this form:

LINE line-name attribute-spec [, attribute-spec ]...

where line-name is the device name of a line and attribute-spec is one of this attribute name and value combinations:


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 ]



Table 14-4 lists the line attributes that have corresponding profile modifiers.

Table 14-4. ALTER LINE Attributes and Corresponding Profile Modifiers (page 1 of 2)


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



For more information on the line attributes that have corresponding profile modifiers, see the description of the corresponding profile modifier in Section 16, Expand Modifiers.

These Line attributes do not have corresponding profile modifiers:

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 14-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 14-6.

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

Table 14-4. ALTER LINE Attributes and Corresponding Profile Modifiers (page 2 of 2)




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 14-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 14-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 or Expand-over-ServerNet 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-over-ATM 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. These are the default values:

TIMERBIND time

specifies the time interval that the Expand-over-NAM or Expand-over-ServerNet 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 14-6.

Expand-over-NAM lines: 20

Expand-over-ServerNet lines 10

Expand-over-IP lines: 19

Expand-over-ATM lines: 19



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 and the default value for Expand-over-ServerNet 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 or Expand-over-ServerNet 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 Expand-over-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 14-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-ATM, or Expand-over-IP line-handler process declares the network unavailable.

The valid ranges for these attribute:

The default values for these attribute:

Expand-over-IP lines: 1 through 32767

Expand-over-ATM lines: 1 through 32767

Expand-over-X.25 lines: 1 through 32767

Expand-over-SNA lines: 1 through 32767

Expand-over-ServerNet lines: 30 through 32767

Expand-over-IP lines: 1

Expand-over-ATM lines: 1



TIMERRECONNECT time

specifies the time interval that the Expand-over-NAM, Expand-over-ATM, Expand-over-IP, or Expand-over-ServerNet 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 14-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-over-IP and Expand-over-ATM lines and 0 through 32767 seconds for Expand-over-NAM and Expand-over-ServerNet 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 Expand-over-ServerNet lines.

Considerations

• You can alter several lines with a single ALTER command by specifying multipleLINE objects using parentheses as:

-> LINE ( line-name , line-name [ , line-name ] ... )

• Except for LINEPRIORITY and DELAY changing any other object attribute requiresthe lines to be in STOPPED state.

Expand-over-X.25 lines: 300

Expand-over-SNA lines: 300

Expand-over-ServerNet lines: 30



Table 14-5 specifies the applicable ALTER LINE attributes for the different types of line-handler processes.

Table 14-5. ALTER LINE Attributes (page 1 of 2)

Attribute

Direct- and Satellite-Connect

Expand-Over-NAM

Expand-Over- ServerNet

Expand-Over-IP

Expand-Over-ATM

AFTERMAXRETRIES X X X X

ASSOCIATEDEV X X X X

ASSOCIATESUBDEV X

ATMSEL X

CALLTYPE X

CLBDWNLOADRETRIES X

CLBDWNLOADTIMR X

CLBIDLETIMER X

CLOCKMODE X

CLOCKSPEED X

CONNECTTYPE X X

DELAY X

DESTATMADDR X

DESTIPADDR X

DESTIPPORT X

DOWNIFBADQUALITY X X X

DSRTIMER X

FLAGFILL X

IDLETIMEOUT X

INTERFACE X

IPVER X

L2DISCARDONRESET X

L2RETRIES X

L2TIMEOUT X X X

LIFNAME X

LINEPRIORITY X X X X X

LINETF X X X X X

MAXRECONNECTS X X X X

PROGRAM X

PVCNAME X



Examples

This SCF command changes the value of the line’s L2TIMEOUT attribute to 10 seconds:

-> ALTER LINE $LINEX, L2TIMEOUT 10.00

This SCF command disables the transmission of FLAGs when the line-handler process $LHBIT is in the idle state:

-> ALTER LINE $LHBIT, FLAGFILL OFF

This SCF command changes the value of the TIMERPROBE attribute for two different lines:

-> ALTER LINE ($LHX251,$LHX252), TIMERPROBE 4:30.50

QUALITYTHRESHOLD X X X

QUALITYTIMER X X X

RETRYPROBE X X X X

RXWINDOW X X

SPEED X X X X X

SPEEDK X X X X X

SRCIPADDR X

SRCIPPORT X

TIMERBIND X X

TIMERINACTIVITY X X X

TIMERPROBE X X X X

TIMERRECONNECT X X X X

TXWINDOW X X X X X

V6DESTIPADDR X

V6SRCIPADDR X

Table 14-5. ALTER LINE Attributes (page 2 of 2)

Attribute

Direct- and Satellite-Connect

Expand-Over-NAM

Expand-Over- ServerNet

Expand-Over-IP

Expand-Over-ATM


Subsystem Control Facility (SCF) Commands ALTER PROCESS Command

ALTER PROCESS CommandThe 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 this syntax:

where attribute-spec for the PROCESS object type for $NCP has this attribute name and value combination:

Table 14-6 lists the $NCP attributes that have corresponding profile modifiers.

For more information on the $NCP attributes that have corresponding profile modifiers, see the description of the corresponding profile modifier in Section 6, Configuring the Network Control Process.

These $NCP attributes do not have corresponding profile modifiers:

ALTER PROCESS $NCP attribute-spec [ attribute-spec ] ...

[ ABORTTIMER time ] [ AUTOREBAL { ON | OFF } ] [ AUTOREBALTIME { time | ( time, start-time ) } ] [ CONNECTTIME time ] [ MAXCONNECTS integer ] [ MAXTIMEOUTS integer ] [ NETWORKDIAMETER integer ] [ REBALTHRESHOLD integer ] [ MSG43 { ON | OFF } ] [ MSG46 { ON | OFF } ] [ MSG48 { ON | OFF } ] [ MSG49 { ON | OFF } ]

Table 14-6. ALTER PROCESS Attributes and Corresponding Profile Modifiers


ABORTTIMER ABORTTIMER n

CONNECTTIME CONNECTTIME n

MAXCONNECTS MAXCONNECTS n

MAXTIMEOUTS MAXTIMEOUTS n

NETWORKDIAMETER NETWORKDIAMETER n

REBALTHRESHOLD REBALTHRESHOLD n


Subsystem Control Facility (SCF) Commands ALTER PROCESS Command

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.

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 run.

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:

[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.


Subsystem Control Facility (SCF) Commands Example

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.

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

This 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 CommandThe 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 this syntax:

* | 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.

DELETE ENTRY $NCP.{ * | system-number | \system-name }



Examples

This SCF command removes from the NRT all the names of systems that are not connected within the network:

-> DELETE ENTRY $NCP.*

This 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 CommandThe INFO command displays the current or default attribute values for the specified objects. INFO is a nonsensitive command.

The INFO command has this syntax:

/ OUT file-spec /

causes any SCF output generated by the command to be directed to the specified file.

PATH path-name


LINE line-name


PROCESS $NCP

indicates the network control process ($NCP).

The OBEYFORM option is used with the INFO command and can be used on the PATH, LINE, and PROCESS object types. The output is in the form of an ALTER command and allows for easy creation of SCF command files. These command files can be used for configuration backup and helps operators to easily restore configuration settings. For more information on OBEYFORM option, see INFO PATH Command on page14-30, INFO LINE Command on page,14-45, and INFO PROCESS Command on page 14-64.

INFO [ / OUT file-spec / ] { PROCESS $NCP | PATH path-name | LINE line-name } [ , DETAIL ]


Subsystem Control Facility (SCF) Commands INFO PATH Command

INFO PATH CommandThe display for a path without the DETAIL option has the format as shown in Example 14-1. The asterisk (*) indicates that the attribute can be altered using the ALTER command, described earlier in this section.

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 14-1. INFO PATH Command

-> INFO PATH $LHPATH EXPAND Info Path Name *Compress *Nextsys *L4Retries *L4Timeout $LHPATH ON #255 3 0:00:20.00



Example 14-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.

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.

See the note under OSSPACE n on page 16-18 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 3 seconds.

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 multi-line path, the line state and number of lines in the path are ignored and the

Example 14-2. INFO PATH, DETAIL Command

-> INFO PATH $LHPATH, DETAIL EXPAND Detailed Info PATH $LHPATH *Compress.... ON *Nextsys........ #255 *OSspace..... 32767 *OStimeout... 0:00:03.00 *L4Retries...... 3 *PathTF.. 1 *L4Timeout... 0:00:20.00 *L4SendWindow... 254 TimeFactor 1 *L4ExtPackets ON *L4CongCtrl..... ON *Superpath... ON

*L4CWNDClamp. 32767 Local Remote Negotiated Maximum *PathBlockBytes 0 0 0 9180 *PathPacketBytes 1024 0 0 9180



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.

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 to support it.

L4CWNDCLAMP

Specifies the maximum value for the congestion control transmit window. The packet rate transmitted over the path does not exceed the L4CWNDCLAMP value. Expand uses a window scale factor of 5, for packet sequencing and window values. To calculate the L4CWNDCLAMP value, use the following formula:

L4CWNDCLAMP = <Congestion_window_size_in_Bytes> / 32

Where,

<Congestion_window_size_in_Bytes> is size of the congestion window

To calculate the size of the congestion window, use the following formula:

<Congestion_window_size_in_Bytes> = bandwidth * delay

Where,

<Congestion_window_size_in_Bytes> is the maximum amount of data on the network circuit in bits. (bandwidth delay product)

bandwidth is the capacity of the data link in bits per second

delay is the end-to-end delay in seconds (round trip time).

You can use the bandwidth delay product (BDP) to calculate the maximum amount of data that can be in transit in the network. It is used to tune systems to the type of network being used. If given the actual data link speed and delay on the network, the network capacity can be calculated. Conversely, If you want to limit the amount of data sent, it can be used to calculate the maximum value to limit or clamp the window.

For more information, see L4CWNDCLAMP n on page 16-13.

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


Subsystem Control Facility (SCF) Commands OBEYFORM Option

OBEYFORM Option

The output is in the form of an ALTER PATH command. This allows for easy creation of SCF command files for configuration backup.

Considerations

You can display information about several paths with a single INFO command by specifying multiple PATH objects using parentheses as:

PATH ( path-name , path-name [ , path-name ] ... )

Example 14-3. INFO PATH $LHPATH, OBEYFORM command

-> INFO PATH $LHPATH,OBEYFORM

ALTER PATH $LHPATH ,& COMPRESS ON ,& NEXTSYS 144 ,& OSSPACE 32767 ,& OSTIMEOUT 0:00:03.00 ,& L4RETRIES 3 ,& PATHTF 0 ,& L4TIMEOUT 0:00:20.00 ,& L4SENDWINDOW 254 ,& L4EXTPACKETS ON ,& L4CONGCTRL ON ,& L4CWNDCLAMP 32767 ,& SUPERPATH 0FF ,& PATHBLOCKBYTES 8192 ,& PATHPACKETBYTES 8192

Note. The OBEYFORM option cannot be used in combination with the DETAIL option.


Subsystem Control Facility (SCF) Commands INFO LINE Command

INFO LINE CommandThe 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 14-4. The asterisk (*) indicates an alterable attribute.

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. For the time interval format, see Time Values on page 14-6. 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 can 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.

Example 14-4. INFO LINE Command, Direct- and Satellite-Connect Line-Handler Processes

-> INFO LINE $SWNLBA1 EXPAND Info LINE Name Address *Delay Framesize *SpeedK *L2Timeout $SWNLBA1 (102,211) 0:00:00.10 132 NOT_SET 0:00:08.25


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. For a discussion of SPEEDK, see SPEEDK n on page 16-23.

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 14-5. The asterisk (*) indicates an alterable attribute.

L2Protocol

lists the name of the Layer 2 protocol process associated with the Expand line-handler process.

TimeFactor

reports the current time factor for this line. For a discussion on time factors, including how to calculate them, see Routing and Time Factors on page 17-22.

SpeedK


Example 14-5. INFO LINE, DETAIL Command, Direct- and Satellite-Connect Line-Handler Processes

-> INFO LINE $SWNLBA1, DETAIL EXPAND Detailed Info LINE $SWNLBA1 (LDEV 310) L2Protocol SWAN_DIRECT TimeFactor...... inf *SpeedK........ NOT_SET Framesize....... 132 -Rsize........... -Speed........ *LinePriority.... 1 StartUp......... OFF *Delay......... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00 *TxWindow........ 7 Address.......(102,211) *Autoload...... ON LineBufSize..... 47288 *Dsrtimer.....0:00:01.00 *Idletimeout... 0:00:10.00 *Interface....... RS232 Readbuffers..... 8 *L2Retries..... 10 DRtimeout..... 0:00:03.00 *CLBidleTimer 0:00:10.00 Threshold..... 500 *L2Timeout..... 0:00:08.25 Protocolid...... 1 Flagfill...... ON *ClockMode...... DCE *ClockSpeed 19200 *CLBdwnloadRetries 3 *CLBdwnloadTimr 0:00:30.00 *Program......... $SYSTEM.CSS12.C1097P00 *LineTf.......... 0



Framesize


Rsize


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



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.



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 line-handler 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.


Subsystem Control Facility (SCF) Commands Expand-Over-IP Line-Handler Processes

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 14-6. The asterisk (*) indicates an alterable attribute.

Name


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


Associatedev

reports the name of the NonStop TCP/IP 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.

Example 14-6. INFO LINE Command, Expand-Over-IP Line-Handler Processes

-> INFO LINE $IPTAH0 Name Delay Framesize *Associatedev *Maxreconnects *Aftermaxretries

$IPTAH0 0:00:00.10 132 $ZTC02 3 PASSIVE



Aftermaxretries

is the line state after 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 14-7 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 14-8 on page 14-38 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 IPv6 display format is the same as the IPv4 display format. If the IPv6 addresses are not set, they are displayed as :: (two colons).

Example 14-7. INFO LINE, DETAIL Command, Expand-Over-IP Line-Handler Processes for IPv4 Lines

-> INFO LINE $IPTAH0, DETAIL EXPAND Detailed Info LINE $IPTAH0 (LDEV 175) L2Protocol Net^Ip TimeFactor...... 3 *SpeedK........ NOT_SET Framesize....... 132 -Rsize........... 3 -Speed........ *LinePriority.... 1 StartUp......... OFF *Delay......... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00 *Txwindow........ 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE *Timerreconnect 0:00:30.00 *Retryprobe...... 19 *Timerprobe.... 0:00:01.00 *Associatedev.... $ZTC02 *LineTf.......... 0 *Timerinactivity 0:00:00.00 *IPVer IPV4 *DestIpAddr 16.107.189.66 *DestIpPort...... 5744 *SrcIpAddr 16.107.188.54 *SrcIpPort....... 5744 *V6DestIpAddr :: *V6SrcIpAddr ::



L2Protocol

is the Layer 2 protocol process associated with the Expand-over-IP line-handler process.

TimeFactor


SpeedK


Framesize

specifies the maximum size frame that can be sent in the network; smaller frames can 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


Speed


Example 14-8. 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 *SpeedK........ NOT_SET Framesize....... 132 -Rsize........... 3 -Speed........ *LinePriority.... 1 StartUp......... OFF *Delay......... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00 *Txwindow........ 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE *Timerreconnect 0:00:30.00 *Retryprobe...... 19 *Timerprobe.... 0:00:01.00 *Associatedev.... $ZTC02 *LineTf.......... 0 *Timerinactivity 0:00:00.00 *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



LinePriority


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


QualityThreshold


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.



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 or TCP6SAM process associated with the Expand-over-IP line-handler process.

LineTF


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.


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 line-handler 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 14-9. The asterisk (*) indicates an alterable attribute.

Name


Delay


Framesize


Example 14-9. INFO LINE Command, Expand-Over-ATM Line-Handler Processes

-> INFO LINE $AMLBA0

EXPAND Info LINE

Name Delay Framesize *Associatedev *Associatesubdev$AMLBA0 0:00:00.10 132 $AM2 #IP



Associatedev

reports the name of the ATM line associated with the Expand-over-ATM line-handler process.

Associatesubdev

reports the name of the ATM service access point (SAP). The only currently supported ATM SAP is #IP.

Example 14-10 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.

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. For a discussion about time factors, including how to calculate them, see Routing and Time Factors on page 17-22.

SpeedK


Framesize


Example 14-10. INFO LINE, DETAIL Command, Expand-Over-ATM Line-Handler Processes

-> INFO LINE $AMLBA0, DETAIL EXPAND Detailed Info LINE $AMLBA0 (LDEV 307) L2Protocol Net^Atm TimeFactor...... 1 *SpeedK........ OC12 Framesize....... 132 -Rsize........... -Speed........ *LinePriority.... 1 StartUp......... OFF Delay......... 0:00:00.10 *DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00 *Txwindow........ 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE *Timerreconnect 0:00:30.00 *Retryprobe...... 19 *Timerprobe.... 0:00:01.00 *Associatedev.... $AM2 *Associatesubdev #IP *Timerinactivity 0:00:00.00 ConnEp....... %H2061CF10 ListenEp.... %H00000000 *CallType...... PVC *PvcName......... PVC10 *LineTf.......... 0



Rsize


Speed


LinePriority


Startup

indicates whether the line will be enabled (ON) or disabled (OFF) after a system load.

Delay


DownIfBadQuality


QualityThreshold


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.



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 line-handler 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.



PvcName

is the name of the permanent virtual circuit (PVC).

LineTF


OBEYFORM Option

The output is in the form of an ALTER LINE command, containing the alterable modifiers for the corresponding line type. This allows for easy creation of SCF command files for configuration backup.

Example 14-11. INFO LINE $<line-name>, OBEYFORM command for Expand over ATM line

-> INFO LINE $ATM,OBEYFORM

ALTER LINE $ATM ,& LINEPRIORITY 1 ,& SPEEDK OC12 ,& QUALITYTIMER 0:01:00.00 ,& QUALITYTHRESHOLD 96 ,& DOWNIFBADQUALITY OFF ,& MAXRECONNECTS 0 ,& AFTERMAXRETRIES PASSIVE ,& TIMERRECONNECT 0:00:30.00 ,& RETRYPROBE 19 ,& TIMERPROBE 0:00:01.00 ,& TIMERINACTIVITY 8:20:50.00 ,& LINETF 0 ,& ASSOCIATEDEV $ATM ,& ASSOCIATESUBDEV #IP ,& CALLTYPE PVC ,& PVCNAME PVC00 ,& TXWINDOW 7



Subsystem Control Facility (SCF) Commands Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes

Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes

For Expand-over-NAM and Expand-over-ServerNet line-handler processes, the display for a LINE object without the DETAIL option has the format as shown in Example 14-12. The asterisk (*) indicates an alterable attribute.

Name


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 can 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.

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.

Associatesubdev

reports the name of the NAM subdevice that will be activated by the Expand-over-NAM 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

Example 14-12. INFO LINE Command, Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes

-> INFO LINE $SC151 EXPAND Info LINE Name Delay Framesize *L2Timeout *Associatedev *Associatesubdev $SC151 0:00:00.10 132 0:00:01.00 $ZZSCL



it is the subdevice name of a SNAX/APN logical unit (LU). This field is not used by Expand-over-ServerNet line-handler processes.

Example 14-13 shows the display format for a LINE object with the DETAIL option for Expand-over-NAM or Expand-over-ServerNet line-handler processes. The asterisk (*) indicates an alterable attribute.

L2Protocol

lists the name of the Layer 2 protocol process associated with the Expand-over-NAM or Expand-over-ServerNet line-handler process.

TimeFactor

reports the current time factor for this line. For a discussion about time factors, including how to calculate them, see Routing and Time Factors on page 17-22.

SpeedK


Framesize

specifies the maximum size frame that can be sent in the network; smaller frames can 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


Example 14-13. INFO LINE, DETAIL Command, Expand-Over-NAM and Expand-Over-ServerNet Line-Handler Processes

-> INFO LINE $SC151, DETAIL 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.... $ZZSCL *Associatesubdev *Timerinactivity 0:00:00.00 *ConnectType..... ACTIVEANDPASSIVE *LineTf.......... 0



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. For a description of the time interval format, see Time Values on page 14-6.

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 or Expand-over-ServerNet line-handler process will wait for a completion of its bind request to the NAM process. For a description of the time interval format, see Time Values on page 14-6.

L2Timeout

specifies the time interval that the line-handler process will wait for a response to request at Layer 2 before retrying. For a description of the time interval format, see Time Values on page 14-6.

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 or Expand-over-ServerNet line-handler process will try a connect request after successfully binding to the NAM interface.

AfterMaxRetries

lists the line state after all retries have been exhausted for the Expand-over-NAM or Expand-over-ServerNet 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 and



Expand-over-ServerNet line-handler processes that have the MAXRECONNECTS modifier set to a nonzero value.

Timerreconnect

specifies the time interval that the Expand-over-NAM or Expand-over-ServerNet line-handler process will wait for a connection request to succeed. For a description of the time interval format, see Time Values on page 14-6.

Retryprobe

reports the number of times that the Expand-over-NAM or Expand-over-ServerNet 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 or Expand-over-ServerNet line-handler process will wait to obtain the status of the NAM process. For a description of the time interval format, see Time Values on page 14-6.

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.

Associatesubdev

reports the name of the NAM subdevice that will be activated by the Expand-over-NAM 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 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. For a description of the time interval format, see Time Values on page 14-6. Timerinactivity does not apply to Expand-over-ServerNet line-handler processes.

Connecttype

lists the Layer 2 Expand-over-NAM or Expand-over-ServerNet 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


Considerations

You can display information about several lines with a single INFO command by specifying multiple LINE objects using parentheses as:

LINE ( line-name , line-name [ , line-name ] ... )

INFO PROCESS CommandThe 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.

The INFO PROCESS command has this syntax:

/OUT file-spec /


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 the paths in the superpath.

INFO [ /OUT file-spec / ] PROCESS $NCP [ , { CONNECTS | LINESET | NETMAP | PATHSET | SUPERPATH | SYSTEMS | RPT system-name } ] [ , AT { system-list | * } ] [ , TO { system-list | * } ] [ , DETAIL ]


Subsystem Control Facility (SCF) Commands INFO PROCESS Command

LINESET

displays the status of a selected path and the status of the started lines that make up that path.

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 in addition to 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.

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.

AT { system-list | * }

where

system-list

is ( [ sys-a [ , sys-b [ , sys-c [ , .... ] ] ] ] ).

sys-a

is {\system-name | system-number }.

sys-b


Note. The LINESET option only displays information on active lines (lines that have been started at least after a system load). To see information on all configured lines, use the SCF command LISTDEV TYPE 63.

Note. If none of the formatting options (LINESET, NETMAP, PATHSET, SUPERPATH, and RPT) are specified, local $NCP information is displayed.



sys-c


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 [ , .... ]]]] ).

sys-a


sys-b


sys-c


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 14-14. The asterisk (*) denotes an alterable attribute.

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).

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.

Example 14-14. INFO PROCESS $NCP Command

-> INFO PROCESS $NCP EXPAND Info PROCESS $NCP AT \NODEA (151) Name AutomaticMaptimer Framesize *Maxtimeouts *Maxconnects $NCP ON #132 3 5



The display for the INFO PROCESS $NCP command with the DETAIL option has the format as shown in Example 14-15. The asterisk (*) denotes an alterable attribute.

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).

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 this formula:. 5 seconds * tf_to_destination, where tf_to_destination is the time factor to the destination system.

Example 14-15. INFO PROCESS $NCP, DETAIL Command

-> INFO PROCESS $NCP, DETAIL EXPAND Detailed Info PROCESS $NCP AT \NODEA (117) Max System Number.. 254 *Aborttimer......... 0:00:40.00 Algorithm.......... MODIFIEDSPLIT AutomaticMaptimer.. ON *Connecttime........ 0:00:00.00 Framesize.......... 132 *Maxtimeouts........ 3 *Maxconnects........ 5 *NetworkDiameter.... 15 Type............... (62,0) *Message 43......... OFF Message 44......... ON Message 45......... ON *Message 46......... OFF Message 47......... ON *Message 48......... OFF *Message 49......... OFF *AutoRebal.......... OFF Next Rebalance Time 0/00:00:00 *AutoRebalTime...... 1/00:00:00 *RebalThreshold..... 0 Trace File Name.... \NODEA.$SYSTEM.SYSTEM.NCPLOG



Framesize

is used by $NCP to compute the maximum size, in words, of a distance vector (DV) packet.

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.

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.

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 16, Expand Modifiers



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 this 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.

SS

shows the seconds.


Subsystem Control Facility (SCF) Commands CONNECTS Option

RebalThreshold

specifies the threshold time for auto-rebalance. It also helps to enable and disable auto-rebalance. RebalThreshold can have the following values:

• -1, the auto-rebalance is switched off and the user must manually trigger rebalance.

• 0, the auto-rebalance occurs normally without taking into cognizance this modifier value.

• Greater than 0, the auto-rebalance occurs if the path has revived after being down beyond the time period mentioned in this modifier.

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 the paths in the multi-CPU path. It is basically a summary of the NETMAP command, but shows only the connected entries.

System

indicates the number and the name of the system, or node.

Example 14-16. INFO PROCESS $NCP Command, CONNECTS Option

-> INFO PROCESS $NCP, CONNECTS EXPAND Info PROCESS $NCP, CONNECTS CONNECTS AT \NODEA (117) #LINESETS=7 TIME: FEB 24,2003 13:55:29 System Time(Dist) Lset:LHname (Ldev) Lset:LHname (Ldev) 82 \NODEB 1(01) 1:$SPATH1 ( 122)& 2:$SPATH0 ( 123)& 3:$SPATH2 ( 121)* 123 \NODEC 4(02) 3:$SPATH2 ( 121)* 160 \NODED 4(02) 5:$IPTAH1 ( 125)+ 254 \NODEE 7(03) 1:$SPATH1 ( 122)*


Subsystem Control Facility (SCF) Commands LINESET Option

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. (For more information on the TF, see Routing and Time Factors on page 17-22.) 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 line-handler processes in the multi-CPU path; an asterisk in this case indicates the line-handler 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:

* 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 14-17:

AT \nnn (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.

Example 14-17. INFO PROCESS $NCP Command, LINESET Option

-> INFO PROCESS $NCP, LINESET EXPAND Info PROCESS $NCP , LINESET LINESETS AT \NODEA (117) #LINESETS=7 TIME: FEB 24,2003 13:55:04 LINESET NEIGHBOR LDEV TF PID LINE LDEV STATUS FileErr# 1 S \NODEB (082) 122 1 ( 1, 334) 1 122 READY 2 S \NODEB (082) 123 1 ( 0, 333) 1 123 READY 3 S \NODEB (082) 121 1 ( 0, 332) 1 121 READY 4 \NODEB (082) 131 -- -- ----- 1 131 NOT READY (066) 5 \NODEB (082) 125 3 ( 2, 271) 1 125 READY 6 \NODEF (247) 132 -- -- ----- 1 132 NOT READY (066) 7 \NODEF (247) 175 -- -- ----- 1 212 NOT READY (066) 2 254 NOT READY (066) 3 256 NOT READY (066) 4 259 NOT READY (066)



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


LDEV


STATUS

indicates the status of the line: ready or not ready.

FileErr#

shows the most recent file system error number, if any, associated with each line.


Subsystem Control Facility (SCF) Commands NETMAP Option

NETMAP Option

The display for the INFO PROCESS $NCP command with the NETMAP option has the format as shown in Example 14-18:

AT \nnn (xxx)

is the name (nnn) and number (xxx) of the system from which the network is viewed.

Example 14-18. 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 TIME (DISTANCE) BY PATH INDEX 82 \NODEB 1(01)& 1(01)& 1(01)* inf(--) 3(01) inf(--) [ 6] inf(--) [ 7] 123 \NODEC 4(02) 4(02) 4(02)* inf(--) 6(02) inf(--) [ 6] inf(--) [ 7] 151 \NODEG inf(--) inf(--) inf(--) inf(--) inf(--) inf(--) [ 6] inf(--) [ 7] 160 \NODED inf(--) inf(--) inf(--) inf(--) inf(--)+ inf(--) [ 6] inf(--) [ 7] 247 \NODEF inf(--) inf(--) inf(--) inf(--) inf(--) inf(--) [ 6] inf(--) [ 7] 254 \NODEE 7(03)* 7(03) 7(03) inf(--) 9(03) inf(--) [ 6] inf(--) [ 7] --------------------------------------------------------------- LINESETS AT \NODEA (117) #LINESETS=7 LINESET NEIGHBOR LDEV TF PID LINE LDEV STATUS FileErr# 1 S \NODEB (082) 122 1 ( 1, 334) 1 122 READY 2 S \NODEB (082) 123 1 ( 0, 333) 1 123 READY 3 S \NODEB (082) 121 1 ( 0, 332) 1 121 READY 4 \NODEB (082) 131 -- -- ----- 1 131 NOT READY (066) 5 \NODEB (082) 125 3 ( 2, 271) 1 125 READY 6 \NODEF (247) 132 -- -- ----- 1 132 NOT READY (066) 7 \NODEF (247) 175 -- -- ----- 1 212 NOT READY (066) 2 254 NOT READY (066) 3 256 NOT READY (066) 4 259 NOT READY (066)


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


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. (For more information on the TF, see Routing and Time Factors on page 17-22.) 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.


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


LDEV




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


LDEV


STATUS


FileErr#

is the last file-system error returned for the path. For recovery information on file errors, see Identifying Network Problems on page 20-3.

OBEYFORM Option

The output is in the form of an ALTER PROCESS command. This allows for easy creation of SCF command files for configuration backup.

Example 14-19. INFO PROCESS $NCP, OBEYFORM command

ALTER PROCESS $NCP ,& AUTOREBAL OFF ,& AUTOREBALTIME 1/00:00:00 ,& REBALTHRESHOLD 0 ,& MSG43 OFF ,& MSG46 OFF ,& MSG48 OFF ,& MSG49 OFF ,& CONNECTTIME 0:00:00.00 ,& ABORTTIMER 0:02:30.00 ,& MAXTIMEOUTS 3 ,& MAXCONNECTS 5 ,& NETWORKDIAMETER 15


Subsystem Control Facility (SCF) Commands PATHSET Option

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 in addition to the other information already in the LINESET option.

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)


TF


Cpu, Pin

uniquely identifies a process. This number consists of the processor number and the process identification number (PIN).


Example 14-20. INFO PROCESS $NCP Command, PATHSET Option

-> INFO PROCESS $NCP, PATHSET EXPAND Info PROCESS $NCP ,PATHSETS PATHSETS AT \NODEA (117) #LINESETS=7 TIME: FEB 24,2003 13:55:18 Ls Neighbor(node) TF (Cpu,Pin) Line Name (LDEV) Status FileErr# 1 S \NODEB (082) 1 ( 1, 334) $SPATH1 ( 122) 1 $SPATH1 ( 122) READY 2 S \NODEB (082) 1 ( 0, 333) $SPATH0 ( 123) 1 $SPATH0 ( 123) READY 3 S \NODEB (082) 1 ( 0, 332) $SPATH2 ( 121) 1 $SPATH2 ( 121) READY 4 \NODEB (082) ----- (--,-----) $IPSTAH ( 131) 1 $IPSTAH ( 131) NOT READY (066) 5 \NODEB (082) 3 ( 2, 271) $IPTAH1 ( 125) 1 $IPTAH1 ( 125) READY 6 \NODEF (247) ----- (--,-----) $IPSFIJ ( 132) 1 $IPSFIJ ( 132) NOT READY (066) 7 \NODEF (247) ----- (--,-----) $IPFIJP ( 175) 1 $IPFIJ02 ( 212) NOT READY (066) 2 $IPFIJ03 ( 254) NOT READY (066) 3 $IPFIJ00 ( 256) NOT READY (066) 4 $IPFIJ01 ( 259) NOT READY (066)


Subsystem Control Facility (SCF) Commands RPT Option

Line

indicates the line number.

Name

indicates the device name of the line.

Ldev


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, see Identifying Network Problems on page 20-3.

RPT Option

The display for the INFO PROCESS $NCP command with the RPT option has the format as shown in Example 14-21:

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

Example 14-21. INFO PROCESS $NCP Command, RPT Option

-> INFO PROCESS $NCP, RPT \NODEA EXPAND Info PROCESS $NCP , RPT SUPERPATHS AT \NODEB (85) #SUPERPATHS=1 TIME: APR 26,2000 13:55:01 S-PATH NEIGHBOR SYS/LDEV SYS/LDEV SYS/LDEV SYS/LDEV 1 \NODEA (102) 80 234 190 245


Subsystem Control Facility (SCF) Commands SUPERPATH Option

entries with valid LDEVs are displayed. For more information on the RPT, see Network Routing Table (NRT) and Multiple Path Table (MPT) on page 17-25.

NEIGHBOR


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 14-22:

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 on the ETF, see Best-Path Route Selection on page 17-24.

NEIGHBOR


LDEV


Example 14-22. INFO PROCESS $NCP Command, SUPERPATH Option

-> INFO PROCESS $NCP, SUPERPATH EXPAND Info PROCESS $NCP , SUPERPATH SUPERPATHS AT \NODEA (117) #SUPERPATHS=1 TIME: FEB 24,2003 13:55:48 S-PATH NEIGHBOR LDEV TF LF LCPU RCPU 1 \NODEB (082) 122 1 1.00 1 1 121 1 1.00 0 2 123 1 1.00 0 0


Subsystem Control Facility (SCF) Commands SYSTEMS Option

TF

indicates super time factors in this display.

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.

System


Example 14-23. INFO PROCESS $NCP Command, SYSTEMS Option

-> INFO PROCESS $NCP, SYSTEMS EXPAND Info PROCESS $NCP, SYSTEMS SYSTEMS AT \NODEA (117) #LINESETS=7 TIME: FEB 24,2003 13:55:37 System Time(Dist) Lset:LHname (Ldev) Lset:LHname (Ldev) 82 \NODEB 1(01) 1:$SPATH1 ( 122)& 2:$SPATH0 ( 123)& 3:$SPATH2 ( 121)* 123 \NODEC 4(02) 3:$SPATH2 ( 121)* 151 \NODEG inf(--) 160 \NODED 32767(--) 5:$IPTAH1 ( 125)+ 247 \NODEF inf(--) 254 \NODEE 7(03) 1:$SPATH1 ( 122)*


Subsystem Control Facility (SCF) Commands SYSTEMS Option

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. (For more information on the TF, see Routing and Time Factors on page 17-22.) 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.


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:

* 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


Subsystem Control Facility (SCF) Commands PRIMARY PROCESS Command

PRIMARY PROCESS CommandThe 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 this syntax:

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.

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 20-33.

• You can switch processors for objects with a single PRIMARY PROCESS command by specifying multiple objects using parentheses as:

PROCESS ( object-name , object-name [ , object-name ] ... )

Examples

This 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

PRIMARY PROCESS { line-name | path-name | $NCP } , cpu-number


Subsystem Control Facility (SCF) Commands PROBE PROCESS Command

This 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

This 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

PROBE PROCESS CommandThe 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 this syntax:

/ OUT file-spec /


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 | system-number command before issuing the PROBE command is equivalent to the AT attribute.


where

system-list is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).

sys-a

is { \system-name | system-number }.

sys-b


sys-c


PROBE [ / OUT file-spec / ] PROCESS $NCP [ , AT { \system-name | system-number } ] [ , TO { system-list | * } ]


Subsystem Control Facility (SCF) Commands PROBE PROCESS Command

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.

Assume that you have entered these 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 14-24:

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

Example 14-24. 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)


Subsystem Control Facility (SCF) Commands START Command

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 \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.

START CommandThe 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 this syntax:

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.

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 { PATH path-name | LINE line-name }



• You can start several lines or paths with a single START command by specifying multiple LINE or PATH objects using parentheses as:

-> LINE ( line-name , line-name [ , line-name ] ... ) -> PATH ( path-name , path-name [ , path-name ] ... )

Examples

This SCF command starts a line named $LHCMP2:

-> START LINE $LHCMP2

This SCF command starts a path named $PTS and all lines associated with it:

-> START PATH $PTS

This SCF commands starts lines named $LHCMP3 and $LHCMP4:

-> START LINE ($LHCMP3,$LHCMP4)

STATS CommandThe 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.

STATS PATH CommandThe STATS PATH command has this syntax:

/ OUT file-spec /


path-name

is the name of the path.

Notes. Analyzing these statistics requires a thorough understanding of the Expand subsystem. For an explanation of the packet types listed below, see Section 17, Subsystem Description.

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 [ / OUT file-spec / ] PATH path-name [ , TO { nnn | \node_name } ] [ , RESET ]


Subsystem Control Facility (SCF) Commands STATS PATH Command

nnn

is the decimal node number.

node-name

is the name of the node, such as \NODEA.

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 14-25:

Example 14-25. STATS PATH Command

-> STATS PATH $ENS21 EXPAND Stats PATH $ENS21, PPID ( 0, 909), BPID ( 1, 1033) Reset Time.... AUG 7,2013 18:35:05 Sample Time.. AUG 7,2013 05:39:54 Current Ext Mem KBytes Used 448 Max Ext Mem KBytes Used 512 Number of Known Systems 0 Number of OOS Timeouts 0 Ext Mem Allocation Fails 0 QIO Allocation Fails 0 Current QIO KBytes Used 0 Max QIO KBytes Used 112 Current QIO MDs Used 0 Max QIO MDs Used 2 Cur Recv Queue Messages 100 Max Recv Queue Messages 400 ------------------------- LEVEL 4 MESSAGE HISTOGRAM ------------------------ <= 64 .. 9474 <= 128 .. 2241 <= 256.. 1314 <= 512 .. 783 <= 1024 .. 3 <= 2048.. 0 <= 4096 .. 5 <= 32K .. 0 > 32K.. 1486 -------------------------- LEVEL 4 DETAIL --------------------------------- SENT: LRQ LCMP CANCEL ACK NAK ENQ PING 16561 2 0 22 0 0 0 RCVD: LRQ LCMP CANCEL ACK NAK ENQ PING 2 7655 0 91 0 1 0 L4 Packets Discarded 4 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 16601 0 7661 8 0 0 8 RCVD: PKTS FORWARDS LINKS CONN TRACE NCPM PCHG 7766 0 2 8 0 0 8 Sent: Av Packets/Frame 1.0 Av Bytes/Frame 101 Rcvd: Av Packets/Frame 1.0 Av Bytes/Frame 103 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 1 ------------------------ QUEUE DEPTHS ------------------------ Security Requests CURRENT 0 MAXIMUM 2 L3 Transfer CURRENT 0 MAXIMUM 0 L3 Waiting LDONE CURRENT 0 MAXIMUM 1 L5 Waiting EXT/Shared Memory CURRENT 0 MAXIMUM 1 L4 Waiting Shared Memory CURRENT 0 MAXIMUM 0 ------------------------ LEVEL 4 / CONGESTION CONTROL ---------------------- Xmit Timeouts 0 ReXmit Timeouts 0 ReXmit Packets 0 ReIdle Timeouts 20



PPID

is the primary process ID.

BPID

is the backup process ID.

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 because 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 because statistics were last reset using the STATS RESET command or because 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 because statistics were last reset using the STATS RESET command or because the line-handler process was started.

QIO Allocation Fails

is the number of QIO memory allocation failures because statistics were last reset using the STATS RESET command or because 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 because 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.

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 because 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.

Cur Recv Queue Messages

indicates the current number of messages in the receive queue. A receive queue is an internal queue used for sending and receiving messages to and from QIO.

Max Recv Queue Messages

indicates the peak number of messages received since the last statistics reset or the line-handler process has started. A receive queue is an internal queue 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 because statistics were last reset using the STATS RESET command, or because 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, because statistics were last reset using the STATS RESET command, or because the line-handler process was started. Sent relates to packets originating from this node. Rcvd refers to packets destined for this node.

These Expand message types reported:

LRQ LINK request LCMP LINK completion message CANCEL CANCEL request ACK ACKNOWLEDGMENT NAK Negative ACKNOWLEDGMENT



ENQ ENQUIRY request PING PING requests and replies

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.

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, because statistics were last reset using the STATS RESET command, or because the line-handler process was started. Sent relates to packets originating from this node. Rcvd refers to packets destined for this node.

These Expand message types reported:

PKTS Packets FORWARDS Packets forwarded LINKS Links CONN CONNECT request TRACE TRACE/PROBE request NCPM $NCP-to-$NCP message PCHG 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.

Note. The sum of PING requests and PING replies is shown because PING requests and PING replies only occur in pairs. The Expand message types are defined and described in Message Handling and Buffer Allocation on page 17-38.



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.

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 because the last reset or line-handler process start, for these 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.

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:


Examples

This SCF command displays statistical information for a path named $PATH1:

-> STATS PATH $PATH1

This SCF command displays statistical information for two paths names $PATH2 and $PATH3:

-> STATS PATH ($PATH2,$PATH3)


Subsystem Control Facility (SCF) Commands STATS PATH NODE Command

STATS PATH NODE CommandThe STATS PATH NODE command has this syntax:

/ OUT file-spec /


path-name

is the name of the path.

TO nnn

is the destination system, where nnn is the decimal node number.

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.

STATS [ / OUT file-spec / ] PATH path-name [ , TO { nnn | \node-name } ] [ , RESET ]



The display for a NODE object has the format as shown in Example 14-26:

PPID


BPID


Reset Time


Sample Time

is the time of the current statistics display.

Example 14-26. STATS PATH NODE Command

SCF > STATS PATH $ENS21,TO \CRYPTO EXPAND Stats PATH $ENS21, PPID ( 0, 909), BPID ( 1, 1033) STATS TO NODE \CRYPTO (254) Reset Time.... AUG 7,2013 17:17:40 Sample Time.. AUG 8,2013 11:15:49 ---------------------------- MESSAGE HISTOGRAM -------------------------- <= 64 .. 1583 <= 128 .. 36 <= 256.. 15 <= 512 .. 8 <= 1024 .. 1 <= 2048.. 2 <= 4096 .. 1 <= 32K .. 0 > 32K.. 1483 ---------------------------- PACKET STATISTICS -------------------------- Control Data Links LRQs LCMPs Sent 10 10467 1556 10452 15 Rcvd 84 1564 9 9 1555 Cancel Ack Nak Enq Ping Sent 0 7 0 3 0 Rcvd 0 84 0 0 0 LCMP Mismatches 0 Packets Discarded 0 ------------------------- CONGESTION CONTROL STATISTICS ----------------- Xmit Timeouts 2 ReXmit Timeouts 4 Rexmit Packets 6 ReIdle Timeouts 5 Current CWND 439 Max CWND 32767 Average RTT (ms) 45 RTT Std Dev (ms) 12 Min RTT (ms) 40 Max RTT (ms) 60 -------------------------------- QUEUE DEPTHS --------------------------- Pending Pend Cancel Transfer Ack Wait CUR 0 0 0 0 0 MAX 1 0 2 2 2 Active Oos CUR 0 0 MAX 0 0



MESSAGE HISTOGRAM

is the overall count of messages sent and received by this node over this path, classified by size in bytes because statistics were last reset using the STATS RESET command, or because 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, because statistics were last reset because the line-handler process was started. Sent relates to packets originating from this node. Rcvd refers to packets destined for this node.

These packet statistics are reported:

Control Control packets Data Data packets Links Links LRQs Link requests LCMPs Link completion messages Cancel Cancel request Ack Acknowledgment Nak Negative Acknowledgment Enq Enquiry request Ping 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.

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.

Average RTT

displays the average Round Trip Time (RTT) value.

RTT Std Dev

displays the RTT Standard Deviation Time value.

Min RTT

displays the Minimum Round Trip Time (RTT) value.

Max RTT

displays the Maximum Round Trip Time value.

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.

Examples

This SCF command displays statistical information for a path named $PATH1:

-> STATS PATH NODE1, TO NODE2

STATS LINE CommandThe STATS LINE command has this syntax:

/ OUT file-spec /


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 14-27:

STATS [ / OUT file-spec / ] LINE line-name [ , RESET ]

Example 14-27. 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 Conn Cmd Conn Resp Data Query Cmd Query Resp Sent 0 0 0 0 0 Rcvd 0 0 0 0 0 Invalid Frames Rcvd 0 Invalid IP Addr Rcvd 0 Frames Dropped 0 Tx Window Available 10 Mem Low 0 Line Quality 100



PPID


BPID


Resettime


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.

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 this 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. For Layer 2 troubleshooting information, see Section 20, Troubleshooting.

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 14-28:

PPID


BPID


Resettime


Example 14-28. 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 Conn Cmd Conn Resp Data Query Cmd Query Resp Sent 0 0 0 0 0 Rcvd 0 0 0 0 0 Invalid Frames Rcvd 0 Invalid ATM Addr Rcvd 0 Frames Dropped 0 Tx Window Available 0 Mem Low 0 Line Quality 100



Sampletime


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.


Subsystem Control Facility (SCF) Commands Expand-Over-ServerNet, Expand-Over-X.25, and Expand-Over-SNA Line-Handler Processes

Line Quality





Expand-Over-ServerNet, Expand-Over-X.25, and Expand-Over-SNA Line-Handler Processes

For Expand-over-ServerNet, Expand-Over-X.25, and Expand-Over-SNA line-handler processes, the display for a LINE object has the format as shown in Example 14-29.

PPID


BPID


Resettime


Example 14-29. 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 Bind Aconn Pconn Query Disc MsgSent 4 4 0 32 0 RepRecv 4 4 0 32 0 MsgTout 0 0 0 0 0 ErrRecv 0 0 0 0 0 LastErr 0 0 0 0 0 Unbind Data Notif Data MsgSent 4 1399463 MsgRecv 0 1364604 RepRecv 4 1399460 RepSent 0 1364604 MsgTout 0 0 ErrSent 0 0 ErrRecv 0 1 LastErr 0 0 LastErr 0 160 Proc lookup failures 0 Inactivity timeouts 0


Subsystem Control Facility (SCF) Commands Expand-Over-ServerNet, Expand-Over-X.25, and Expand-Over-SNA Line-Handler Processes

Sampletime


Bind

indicates the line handler bind to an associate device (such as $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 $ZZSCL or $X25AM). The line handler unbinds with the associate device when it aborts.

Data

indicates the number of data frames sent. Normal ServerNet traffic is not counted here because normal data traffic by-passes the line handler for these processes.

Notif

indicates the notification message (NAM protocol). The Expand line handler does not originate the notification message, but must receive it. The associate device


Subsystem Control Facility (SCF) Commands SWAN Concentrator Lines

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 ServerNet traffic is 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 because of inactivity. Used for Expand-over-X25 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 14-30:

PPID


Example 14-30. STATS LINE Command, SWAN Concentrator Lines

-> STATS LINE $SWNLCW1 EXPAND Stats LINE $SWNLCW1, PPID ( 2, 20), BPID ( 3, 21) Resettime... JUN 12,2000 09:29:43 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 DETAIL ----------------------------------- SABM DISC UA DM CMDR RR Sent 7 0 0 2 0 890 Rcvd 1 1 1 6 0 898 RNR REJ SREJ I-FRM I-FRM(P) Sent 0 0 0 227 0 Rcvd 0 0 0 220 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



BPID


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) because statistics were last reset using the STATS RESET command or because the line-handler process was started. The headings see 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 because 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 because the last time the statistics were reset.

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. For more information on troubleshooting Layer 2 problems, see Section 20, Troubleshooting.



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.

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 because THRESHOLD



number of frames was last transmitted. THRESHOLD applies only to lines attached to the SWAN concentrator.

Line Quality





No Buffer

is the number of times read buffer space for the driver could not be obtained to read a frame because 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 because the THRESHOLD number of frames was last transmitted.

BCC Errs

is the number of invalid frames received from the CSS driver because 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 because statistics were last reset using the STATS RESET command or because the line-handler process was started.

Rcv OverRun

is the number of frames received that were longer than the maximum frame size expected because statistics were last reset using the STATS RESET command or because 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, because statistics were last reset using the STATS RESET command or because 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.

Considerations

You can display statistics for several lines with a single STATS LINE command by specifying multiple LINE objects using parentheses as:


Examples

This SCF command displays the statistical information for a line named $LHSL1:

-> STATS LINE $LHSL1



This SCF command displays the statistical information for two lines named $LHSL2 and $LHSL3:

-> STATS LINE ($LHSL2,$LHSL3)


Subsystem Control Facility (SCF) Commands STATS PROCESS Command

STATS PROCESS CommandThe STATS PROCESS command displays statistical information about the network control process ($NCP).

Depending on the option you choose, the STATS command for $NCP displays these 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 this syntax:

/ 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.

AT { system-list | * }

where

system-list

is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).

sys-a


sys-b


sys-c


STATS [ / OUT file-spec / ] PROCESS $NCP [ , { NETFLOW | LOCALFLOW } ] [ , AT { system-list | * } ] [ , TO { system-list | * } ]



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.


where

system-list

is ( [ sys-a [ , sys-b [ , sys-c [ , .... ]]]] ).

sys-a


sys-b


sys-c


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.

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 this 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 14-31 (example display of $NCP statistics with NETFLOW option):

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 because the line-handler process was started.

TOTAL PKTS-SENT

reports the total number of packets sent from this system to a selected system because the line-handler process was started.

TOTAL LINKS-RCVD

reports the total number of link requests received by this system from a selected system because the line-handler process was started.

Example 14-31. 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 STATISTICS AT \N1 (003) TOTAL TOTAL TOTAL TOTAL SYSTEM LINKS-SENT PKTS-SENT LINKS-RCVD PKTS-RCVD 2 \NODEB 469 1133 102 1132 4 \NODET 0 0 0 0 5 \NODEC 0 0 0 0 6 \NODER 0 0 0 0 7 \NODEA 47 110 8 110 9 \NODEH 6 165 54 114 10 \NODEW 0 0 0 0 13 \NODEX 0 0 0 0 14 \NODET 0 0 0 0 15 \NODE1 0 0 0 0



TOTAL PKTS-RCVD

reports the total number of packets received by this system from a selected system because the line-handler process was started.

Assume that you have entered this command:

-> STATS PROCESS $NCP, LOCALFLOW, AT (\NODEC,\NODET,5,6,7,9)

The resulting display has the format as shown in Example 14-32:

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.

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.

Example 14-32. 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 TOTAL TOTAL TOTAL TOTAL SYSTEM PKTS-SENT PKTS-RCVD PASSTRU-SENT PASSTRU-RCVD 2 \NODEC 23784 20874 9876 1132 4 \NODET 14567 32421 7289 28292 5 \NODEW 26735 23451 10002 10627 6 \NODER 31765 26547 8902 9028 7 \NODEA 24567 34582 5901 8976 9 \NODEH 30921 28906 9876 11192


Subsystem Control Facility (SCF) Commands STATUS Command

STATUS CommandThe 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 this syntax:

/ OUT file-spec /


PATH path-name


LINE line-name


STATUS PATH CommandThe display for a path without the DETAIL option has the format as shown in Example 14-33:

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.

STATUS [ / OUT file-spec / ] { PATH path-name | LINE line-name } [, DETAIL ]

Example 14-33. STATUS PATH Command

-> STATUS PATH $LHPATH2 EXPAND Status PATH Name State PPID BPID Lines # $LHPATH2 STARTED 1, 20 2, 26 1


Subsystem Control Facility (SCF) Commands STATUS PATH Command

PPID


BPID


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 14-34:

PPID


BPID


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.

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

Example 14-34. STATUS PATH, DETAIL Command

-> STATUS PATH $PATM4WI, DETAIL EXPAND Detailed Status PATH $PATM4WI PPID........ ( 1, 295) BPID........... ( 2, 270) State....... STARTED Number of Lines.. 4 Trace Status OFF Superpath........ OFF Line LDEVs.. 148 184 189 347 Trace File Name.... none



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


Considerations

You can display the status information for several paths with a single STATUS PATH command by specifying multiple PATH objects using parentheses as:


Examples

This SCF command summarizes the status on path $PATH1:

-> STATUS PATH $PATH1

This SCF command gives a detailed display of the status on path $PATH1:

-> STATUS PATH $PATH1, DETAIL

This 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 14-35:

Name


State

indicates the summary state of the line. The line is in either the STARTED or STOPPED state.

Example 14-35. STATUS LINE Command

-> STATUS LINE $SWNLCW1 EXPAND Status LINE Name State Status PPID BPID CIU-Path ConMgr-LDEV $SWNLCW1 STARTED READY 2, 20 3, 21 A 70


Subsystem Control Facility (SCF) Commands STATUS LINE Command

STATUS


PPID


BPID


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 14-36:

PPID


BPID


State

indicates the summary state of the line. The line is in either the STARTED or STOPPED state.

Example 14-36. STATUS LINE, DETAIL Command, Direct- and Satellite-Connect Line-Handler Processes

-> STATUS LINE $SWNYE2, DETAIL EXPAND Detailed Status LINE $SWNYE2

PPID............... ( 2, 327) BPID................. ( 3, 277)State.............. STARTED Path LDEV............ 303Trace Status....... OFF Clip Status.......... LOADEDConMgr-LDEV........ 72 Status READYSWAN Track Id...... X017NU Clip................. 1Line............... 1 Path................. BIP Address......... 172.17.208.82 Effective line priority 1Trace File Name.... none



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


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.

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


For an Expand-over-IP, Expand-over-ATM, Expand-over-ServerNet, or Expand-over-NAM line-handler process, the display for a LINE object with the DETAIL option has the format as shown in Example 14-37:

PPID


BPID


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.

Detailed State

indicates a more detailed state. These are the detailed states:

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.

Example 14-37. STATUS LINE, DETAIL Command, LINE Object

-> STATUS LINE $SC151, DETAIL EXPAND Detailed Status LINE $SC151 PPID............... ( 2, 282) BPID................. ( 3, 282) State.............. STARTED Path LDEV............ 109 Trace Status....... OFF Effective line priority 1 Detailed State..... CONNECTED Status READY Detailed Info... None Trace File Name.... \NODEA.$DATA00.STATUS.TRC



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


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 line-handler 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


SOCKET SETUP


SOCKET_SPACE




WAIT

indicates that the Expand line-handler process is waiting for another process or subsystem. For more information, see the Detailed Info field.

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-over-ATM line-handler process; this field is not displayed for Expand-over-NAM or Expand-over-ServerNet 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 14-7 lists the messages and their corresponding event numbers.

Trace File Name


Table 14-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

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



For cause, effect, and recovery information for the event numbers generated by the Expand subsystem, see the Operator Messages Manual.

Considerations

You can display the status information for several lines with a single STATUS LINE command by specifying multiple LINE objects using parentheses as:


Examples

This SCF command summarizes the status on line $LINE1:

-> STATUS LINE $LINE1

This SCF command gives a detailed display of the status on path $LINE1:

-> STATUS LINE $LINE1, DETAIL

This SCF command summarizes the status on paths $LINE2 and $LINE3:

-> STATUS PATH ($LINE2,$LINE3)

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

Table 14-7. Messages and Corresponding Event Numbers (page 2 of 2)



Subsystem Control Facility (SCF) Commands STOP Command

STOP CommandThe 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 this syntax:

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 14-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:

PATH ( path-name , path-name [ , path-name ] ... ) LINE ( line-name , line-name [ , line-name ] ... )

Examples

This SCF command stops the line named $LHCMP2:

-> STOP LINE $LHCMP2

This SCF command stops all lines associated with the path named $PTS:

-> STOP PATH $PTS

This SCF command stops the lines named $LHCMP3 and $LHCMP4:

-> STOP LINE ($LHCMP3,$LHCMP4)

STOP { PATH path-name | LINE line-name }


Subsystem Control Facility (SCF) Commands TRACE Command

TRACE CommandThe 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 15, Tracing.

The TRACE command has this syntax for tracing Expand paths:

The TRACE command has this syntax for tracing Expand lines:

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

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



The TRACE command has this syntax for tracing the network control process ($NCP):

/ OUT file-spec /


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 before 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.

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



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 can 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 to avoid truncating the data records.

SELECT select-spec

select-spec is one of the parameter specification combinations described in Table 14-8, Table 14-9 on page 14-115, or Table 14-10 on page 14-115. You can specify either the keyword or the bit number.

The select-spec for $NCP is described in Table 14-8.

Table 14-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


4 System abort message 6

4 System connect message 6

ALL 0-31 Sets all trace record types



The select-spec for the LINE object is described in Table 14-9.

The select-spec for PATH objects is described in Table 14-10.

Table 14-9. LINE Object Trace Records

Mask Trace Record


L0 0 Frames out, nonextended1 0

0 Frames in, nonextended1 1

0 Frames out, extended1 7

0 Frames in, extended1 8


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.

Table 14-10. PATH Object Trace Records (page 1 of 2)

Mask Trace Record


L0 0 Frames out, nonextended* 0

0 Frames in, nonextended* 1

0 Frames out, extended* 7

0 Frames in, extended* 8



4 Line-handler process to $NCP message

5

*Applies only to paths not attached to a ServerNet wide area network (SWAN) concentrator.



TO file-spec

file-spec specifies the file to which tracing is to be initiated. The file might 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 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 handled as a LINE object.

• You can trace several objects with a single TRACE command by specifying multiple objects using parentheses as:

PATH ( path-name , path-name [ , path-name ] ... ) LINE ( line-name , line-name [ , line-name ] ... )

4 System abort messages 6

L5 5 Security events 198

ALL 0-31 Sets all 32 bits

Table 14-10. PATH Object Trace Records (page 2 of 2)

Mask Trace Record


*Applies only to paths not attached to a ServerNet wide area network (SWAN) concentrator.



Examples

This 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

This SCF command terminates an existing trace of path $PATH1:

-> TRACE PATH $PATH1, STOP

This SCF command initiates a trace of the network control process:

-> TRACE PROCESS $NCP, TO NCPTRC, SELECT ALL, RECSIZE 500, WRAP

This SCF command initiates a trace of two lines named $LINE2 and $LINE3:

-> TRACE LINE ($LINE2,$LINE3)

VERSION CommandThe 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 this syntax:

/ OUT file-spec /


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 line-handler process.

• You can display version information for several objects with a single VERSION command by specifying multiple objects using parentheses as:

PROCESS ( object-name , object-name [ , object-name ] ... )

VERSION [ / OUT file-spec / ] PROCESS { process-name | $NCP | $ZEXP }



Examples

These examples show the version information returned for a specified process.

VERSION PROCESS CommandExample 14-38 shows the displays for the VERSION PROCESS command:

Example 14-38. VERSION PROCESS Command

-> VERSION PROCESS $SC254, DETAIL Detailed VERSION PROCESS \DRP25.$SC254 SYSTEM \DRP25 EXPAND (LH) - T9057H01 - (01OCT2004_07DEC04_H01 GUARDIAN - T9050 - (R06) SCF KERNEL - T9082H01 - (01OCT04) (27APR04) EXPAND PM - T9117H01 - (01OCT2004) - (06DEC04)


15 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.

• Why Tracing Is Important on page 15-2

• How to Use Tracing on page 15-2

• Tracing Using SCF on page 15-3

• PTrace Command Overview on page 15-5

• FILTER Command on page 15-6

• FIND Command on page 15-7

• FROM Command on page 15-8

• HEX Command on page 15-8

• LABEL Command on page 15-9

• NEXT Command on page 15-9

• OCTAL Command on page 15-10

• OUT Command on page 15-11

• RECORD Command on page 15-11

• SELECT Command on page 15-12

For general information about PTrace, see the PTrace Reference Manual. For more information on the SCF TRACE command, see TRACE Command on page 14-112.

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.


Tracing Why Tracing Is Important

Why Tracing Is ImportantTracing 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 TracingFor 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 4-megabyte 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


-> TRACE PATH $path-name, STOP

$path-name specifies the name of the path logical device or single-line Expand line-handler process. $file-name specifies the name of the file to which the trace records will be written.


Tracing Tracing a Line in a Multi-Line Path

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


-> 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 SCFTo trace records, you enter the SCF TRACE command using keywords to select records (see TRACE Command on page 14-112 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.

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. After 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. After 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.

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.


Tracing Tracing Using SCF

Figure 15-1 shows the relationship of the tracing process components when SCF is used.

Figure 15-1. Tracing Process Using SCF

VST052.vsd

SCP

ExpandManager($ZEXP)

SCP TRACECOLLECTOR

DiskFile

Ptrace Facility

Expand PMFilter Select

SCF Trace Commandfor $NCP, LINE,

or PATH

PTraceCommand

SelectedTrace RecordsFormatted

SPI Command SPI Response

Bit Mask

Bit Maskfor $NCP

Bit Mask forLINE or PATH

SCFSelectedRecords

SCFSelectedRecords

TracedRecords

Trace Records

File-SystemProcedure

ExpandLine Handler

SCP TRACE

$NCP

SCP TRACE

Expand PM

SCF


Tracing PTrace Command Overview

PTrace Command OverviewConsider these, when you are using the PTrace facility:

• 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 15-1 briefly describes commands that are useful when formatting Expand trace records using the PTrace facility.

For details about the PTrace facility, see the PTrace Reference Manual. The remainder of this section describes the commands that are of particular interest to persons tracing Expand information.

Table 15-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.


Tracing FILTER Command

FILTER CommandThe FILTER command prevents the selected type of information from being sent to the output device.

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 these ways:

• Issue the FROM command• Issue the FILTER command again• Issue the FILTER command with the RESET option

FILTER { option | option,option,...option | RESET }


Tracing Examples

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 NOL2, NOL4, and NODATA selection options do not apply. If you want to filter state machine information, use the SELECT command.

Examples

This command filters Layer 2 Receive Ready (RR):

?FILTER NOL2RR

This command resets the filter to the default, so no information is filtered:

?FILTER RESET

FIND CommandThe 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.

BOTH

specifies that you want the search to be case-insensitive; that is, that PTrace should handle 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 record in which the previously specified string parameter was found. However, if you

F[IND] [ [ B[OTH] ] "string" ]


Tracing Examples

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

This example searches the trace file for both uppercase and lowercase occurrences of the character string EXPAND03:

?FIND BOTH "EXPAND03"

This example searches for the next occurrence of a previously specified string:

?FIND

FROM CommandThe 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.

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 CommandThe HEX command, if set to ON, prints the data portion of a trace record, including the record header, in hexadecimal format.

ON | OFF

ON enables printing in hexadecimal format. OFF disables printing in hexadecimal format and enables printing in octal format. The default is OFF.

FROM file-name

HEX { ON | OFF }


Tracing Example

Example

?HEX ON

LABEL CommandThe 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.

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 CommandThe 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.

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. After 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.

LABEL { ON | OFF }

N[EXT] [ count ] [ AFTER timestamp ] [ F-key ]


Tracing Example

F-key

is pressed to specify the number of lines to display at the 6530 terminal. Table 15-2 lists the number of lines that are sent when specific function keys are pressed.

Example

?NEXT 15 AFTER 13:01

OCTAL CommandThe OCTAL command, when set to ON, prints the data portion of a trace record, including the record header, in octal format.

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

Table 15-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

OCTAL { ON | OFF }


Tracing OUT Command

OUT CommandThe OUT command allows you to direct trace records from your terminal screen to the spooler or to a line printer.

file-name

specifies the name of the spooler or line printer to which you want to direct the trace records.

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 CommandThe 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.

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.

OUT [ TO file-name ] | STOP

RECORD [ first ] | first,last | ALL

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.


Tracing Examples

Examples

This example displays records numbered 1 through 36:

?RECORD 1/36

This example displays records numbered 5 through 200:

?RECORD 5,200

SELECT CommandThe 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.

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 15-3.

keyword

is one of the keywords listed in Table 15-3.

Table 15-3 shows the SELECT options that have meaning when formatting Expand traces.

SELECT [mask [, mask ] ...] | [ mask [, keyword ] ...]

Table 15-3. SELECT Options for Expand (page 1 of 2)

Keyword SCF Bit Hex Mask Octal Mask Lin

e

PA

TH

$NC

P

Description

L0 00 %H80000000 %20000000000

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 Packets sent by $NCP


Tracing SELECT Command

L2 02 %H20000000 %04000000000

X X Layer 2 events

L3 03 %H10000000 %02000000000

X Layer 3 events

L4 04 %H08000000 %01000000000

X X X Layer 4 events

X Expand line-handler process to $NCP messages

X X System ABORT messages

X System CONNECT messages

X X EMS messages

L5 05 %H04000000 %00400000000

X X Security events

DI 09 %H00800000 %00020000000

X X Frames in, SWAN concentrator

X X Frames in, IP packets

DO 09 %H00400000 %00020000000

X X Frames out, SWAN concentrator

X X Frames out, IP packets

CLBI 10 %H00200000 %00010000000

X CLB inbound frames, SWAN concentrator

CLBO 11 %H00100000 %00004000000

X CLB outbound frames, SWAN concentrator

CLIPDI 15, 16 %H00018000 %00000300000

X CLIP inbound frames, SWAN concentrator

CLIPDO 15, 17 %H00014000 %00000240000

X CLIP outbound frames, SWAN concentrator

CLIPL2 15, 21 %H00010400 %00002020000

X CLIP requests and responses, CLIP Layer 2 state machine, frames in and out

ALL 0 to 31 %HFFFFFFF %37777777777

X CLIP requests and responses, CLIP Layer 2 state machine, frames in and out

Table 15-3. SELECT Options for Expand (page 2 of 2)

Keyword SCF Bit Hex Mask Octal Mask Lin

e

PA

TH

$NC

P

Description


Tracing SELECT Command



Part IV consists of these sections, which provide reference information:

Section 16 Expand Modifiers

Section 17 Subsystem Description


16 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 SectionThe 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 ModifiersRequired modifiers are modifiers that are necessary for successful network operation. Not all modifiers are required for all types of Expand line-handler processes. Table 16-1 lists the required modifiers.

Table 16-1. Required Modifiers (page 1 of 3)

Modifier Description

ASSOCIATEDEV Can be used to associate:

• The logical device name of a NAM process with an Expand-over-NAM line-handler process.

• A NonStop TCP/IP process with an Expand-over-IP line-handler process.

• An Asynchronous Transfer Mode (ATM) line with an Expand-over-ATM line-handler process.

• The ServerNet monitor process ($ZZSCL) with an Expand-over-ServerNet 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 line-handler processes. There is no default value for Expand-over-NAM, Expand-over-IP, and Expand-over-ATM line-handler processes.


Expand Modifiers Required Modifiers

ASSOCIATESUBDEV Must be used to specify

• The name of the X25AM subdevice to which an Expand-over-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 line-handler processes; the default value is #IP for Expand-over-ATM line-handler processes (the only value allowed for Expand-over-ATM).

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

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 line-handler 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.




Expand Modifiers Required Modifiers

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.


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.*

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 line-handler 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 line-handler 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.


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.


Default: 0000:0000:0000:0000:0000:0000:0000:0000.

*The default value for this modifier is invalid and must be changed.




Expand Modifiers Modifier Dictionary

Modifier DictionaryThis 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: AFTERMAXRETRIES_DOWN Units: Not applicable Range: Not applicable

These modifiers are applicable to Expand-over-NAM, Expand-over-IP, Expand-over-ATM, and Expand-over-ServerNet line-handler processes only.

The AFTERMAXRETRIES_DOWN modifier causes the Expand line-handler process to go to the DOWN state after 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 after the maximum number of retries (as specified by the MAXRECONNECTS modifier) has been exhausted. For Expand-over-NAM and Expand-over-ServerNet 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: $ZZSCL for Expand-over-ServerNet 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 Units: Not applicable Range: Any eight-character string

This modifier is used for Expand-over-NAM, Expand-over-IP, Expand-over-ATM, and Expand-over-ServerNet 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.


Expand Modifiers ASSOCIATESUBDEV #n

ASSOCIATESUBDEV #n

Default: No default for Expand-over-NAM line-handler processes #IP for Expand-over-ATM line-handler processes Units: Not applicable Range: Not applicable

This modifier is required for Expand-over-NAM and Expand-over-ATM line-handler processes only. n might specify these:

• 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-over-SNA 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: %H80 Units: Not applicable Range: 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: CALLTYPE_PVC Units: Not applicable Range: 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 Modifiers CLBIDLETIMER

CLBIDLETIMER

Default: 10 Units: Seconds Range: 0.001 through 5:27.0

This modifier is applicable only to SWAN SAT line, which applies to the connection from the NonStop operating system to the SWAN adapter. Default value is the best value. When the data connection from the operating system to the SWAN adapter is idle, the Timer determines how often the linehandler process on the operating system will send a status probe to the SWAN adapter.

CLOCKMODE_DCE/CLOCKMODE_DTE

Default: CLOCKMODE_DCE Units: Not applicable Range: Not applicable

These modifiers are applicable to direct-connect and satellite-connect Expand line-handler 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 with the CLOCK modifier.

CLOCKSPEED_600/CLOCKSPEED_1200 CLOCKSPEED_2400/CLOCKSPEED_4800 CLOCKSPEED_9600/CLOCKSPEED_19200 CLOCKSPEED_38400/CLOCKSPEED_56000 CLOCKSPEED_115200

Default: CLOCKSPEED_19200 Units: Kilobits per second (Kbps) Range: Not applicable

These modifiers are applicable to direct-connect and satellite-connect Expand line-handler 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.


Expand Modifiers COMPRESS_OFF/COMPRESS_ON

COMPRESS_OFF/COMPRESS_ON

Default: COMPRESS_ON Units: Not applicable Range: 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).

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.

CONNECTTYPE_ACTIVEANDPASSIVE/ CONNECTTYPE_PASSIVE

Default: CONNECTTYPE_ACTIVEANDPASSIVE Units: Not applicable Range: ON or OFF

These modifiers are applicable to Expand-over-NAM, Expand-over-IP, Expand-over-ATM, and Expand-over-ServerNet line-handler processes.

For Expand-over-NAM and Expand-over-ServerNet 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 and Expand-over-ServerNet 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.


Expand Modifiers DELAY n

For Expand-over-IP and Expand-over-ATM line-handler processes, the CONNECTTYPE_PASSIVE modifier indicates that the Expand-over-IP or Expand-over-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.

DELAY n

Default: 10 (0.10 second) Units: Milliseconds Range: 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 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 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: (ISONSAP:%H0000000000000000000000000000000000000000) Units: Not applicable Range: 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 line-handler 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.


Expand Modifiers DESTIPADDR n

DESTIPADDR n

Default: 0.0.0.1 Units: Not applicable Range: 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) Expand-over-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.

DESTIPPORT n


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 line-handler 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: OFF Units: Not applicable Range: 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: 8192 Kbytes (4 megabytes) Units: Kbytes Range: 0 through 32767 Kbytes (32 megabytes)

This modifier allows you to specify the base size of extended memory for Expand’s internal buffer pool.


Expand Modifiers FLAGFILL_OFF/ FLAGFILL_ON

FLAGFILL_OFF/ FLAGFILL_ON

Default: FLAGFILL_ON Units: Not applicable Range: 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.

FRAMESIZE n


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 can 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 this 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 17, Subsystem Description.

INTERFACE_RS232/INTERFACE_RS422

Default: INTERFACE_RS232 Units: Not applicable Range: 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.

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.


Expand Modifiers IPVER_IPV4/IPVER_IPV6

IPVER_IPV4/IPVER_IPV6

Default: IPv4 Units: Not applicable Range: Not applicable

This modifier specifies whether to create an IPv4 or an IPv6 socket. If IPv4, the ASSOCIATEDEV parameter can see 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 see NonStop TCP/IPv6 and the V6SRCIPADDR and V6DESTIPADDR modifiers are used for the local and remote IP addresses.

L2DISCARDONRESET_OFF/L2DISCARDONRESET_ON

Default: L2DISCARDONRESET_ON Units: Not applicable Range: ON or OFF

These Layer 2 modifiers are applicable to direct-connect and satellite-connect line-handler 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: 20 for Expand-over-IP and Expand-over-ATM 10 for all other line types Units: Not applicable Range: 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 this 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


Expand Modifiers L2TIMEOUT n

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.

L2TIMEOUT n

Default: 100 (1.00 second) for direct-connect lines 200 (2.00 seconds) for satellite-connect lines Units: 0.01 seconds Range: 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 this 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 remember 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 this 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 this algorithm:

(((txw + 1) * pathpacketbytes * 8) / (lspd / 100)) + (2 * dl) + 10

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 Modifiers L4CONGCTRL_OFF/L4CONGCTRL_ON

The result of these algorithms is a one-hundredth of a second value.

For more information on the multipacket frame and variable packet size features, see Section 17, Subsystem Description.

L4CONGCTRL_OFF/L4CONGCTRL_ON

Default: L4CONGCTRL_ON for Expand-over-IP and Expand-over-ATM lines L4CONGCTRL_OFF for other line types and multi-line paths Units: Not applicable Range: 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 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 17, Subsystem Description, before using this modifier.

L4CWNDCLAMP n

Default: 32767 Units: Integers Range: 2000-2147483647

The path modifier is applicable to all Expand line types if the congestion control feature is enabled (L4CONGCTRL_ON). It specifies the maximum value for the congestion control transmit window. The packet rate transmitted over the path does not exceed the L4CWNDCLAMP value. Expand uses a window scale factor of 5, for packet sequencing and window values. To calculate the L4CWNDCLAMP value, use the following formula:

L4CWNDCLAMP = <Congestion_window_size_in_Bytes> / 32

Where,

<Congestion_window_size_in_Bytes> is size of the congestion window

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 this command:

ALTER LINE $device_name, L2TIMEOUT 3.00.


Expand Modifiers L4EXTPACKETS_OFF/L4EXTPACKETS_ON

To calculate the size of the congestion window, use the following formula:

<Congestion_window_size_in_Bytes> = bandwidth * delay

Where,

<Congestion_window_size_in_Bytes> is the maximum amount of data on the network circuit in bits. (bandwidth delay product)

bandwidth is the capacity of the data link in bits per second

delay is the end-to-end delay in seconds (round trip time).

You can use the bandwidth delay product (BDP) to calculate the maximum amount of data that can be in transit in the network. It is used to tune systems to the type of network being used. If given the actual data link speed and delay on the network, the network capacity can be calculated. Conversely, If you want to limit the amount of data sent, it can be used to calculate the maximum value to limit or clamp the window.

Example

Consider a data link speed of 50 megabits per second and a delay of 200 milliseconds. Therefore, the maximum congestion window capacity is calculated as:

50,000,000 bits per second X 0.200 seconds = 10,000,000 bits

This means, the path can have 10,000,000 bits (or 1,250,000 byte) outstanding before an ack is required. When this window capacity is in use, the data link is fully utilized.

To set a limit on the bandwidth to be used, use the cwnd (L4CWNDCLAMP) clamp. To calculate the cwnd clamp value, choose the desired maximum amount of bandwidth the path should use and then, using the BDP formula, calculate the cwnd clamp size. For example, to limit the path to use only 30 megabits of the 50 megabit link, the calculation is as follows:

30,000,000 bits per second X 0.200 seconds = 6,000,000 bits

And convert the cwnd clamp value to bytes. Applying Expand's window scale factor gives a clamp value of 23437.

6,000,000 / 8 = 750,000 bytes

75,000 bytes / 32 = 23437 (L4CWNDCLAMP)

L4EXTPACKETS_OFF/L4EXTPACKETS_ON

Default: L4EXTPACKETS_ON Units: Not applicable Range: 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

Note. The congestion control feature must be enabled through the modifier L4CONGCTRL_ON to use the L4CWNDCLAMP modifier.


Expand Modifiers L4RETRIES n

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 lower-speed lines.

L4RETRIES n


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) request before reporting an error. You should read the description of Layer 4 retries in Section 17, Subsystem Description, before using this modifier.

L4SENDWINDOW n

Default: 254 Units: Packets Range: 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 cause the retransmission of many packets during error-recovery 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.

Note. The L4RETRIES modifier value should be set to the same value for every Expand line-handler process on every node in the network.


Expand Modifiers L4TIMEOUT n

L4TIMEOUT n

Default: 2000 (20.00 seconds) Units: 0.01 seconds Range: 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 17, 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).

This 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 16-11.)

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 16-12.)

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.

LIFNAME n

Default: None Units: Not applicable Range: 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).

Note. The L4TIMEOUT modifier should be set to the same value for every Expand line-handler process on every node in the network.


Expand Modifiers LINEPRIORITY n

LINEPRIORITY n

Default: 1 Units: Integers Range: 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: 0 (unset) Units: Not applicable Range: 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 handler will display a configuration error. For more information on establishing time factors, see Setting Time Factors on page 17-23.

MAXRECONNECTS n


This modifier is applicable to Expand-over-NAM, Expand-over-IP, Expand-over-ATM, and Expand-over-ServerNet line-handler processes.

For Expand-over-NAM and Expand-over-ServerNet line-handler processes, this modifier specifies the maximum number of times the Expand line-handler 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 line-handler 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.


Expand Modifiers NEXTSYS n

NEXTSYS n


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


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 multi-line paths might require all Expand line-handler processes to have more than the default buffer size for storing OOS packets.

OSTIMEOUT n

Default: 300 (3 seconds) Units: 0.01 seconds Range: 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 line-handler 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.

Note. The OSSPACE modifier is currently ignored. The amount of space allocated to out-of-sequence (OOS) packets is limited by the OSTIMEOUT modifier and by the base size of the line handler’s data segment. The OSSPACE modifier can be used in the future, in which case its default, units, and range might be different. For this reason, the recommended setting for OSSPACE is to not specify it, but to let the default be used.


Expand Modifiers PATHBLOCKBYTES n

PATHBLOCKBYTES n

Default: 0 Units: Bytes Range: 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 17, Subsystem Description, before using this modifier.

The value of n must be larger than the result of this 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 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: 1024 Units: Bytes Range: 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 17, 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 this equation:

n > framesize * 4


Expand Modifiers PATHTF n

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.

PATHTF n

Default: 0 (unset) Units: Not applicable Range: 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. For more information on establishing time factors, see Setting Time Factors on page 17-23.

PROGRAM n

Default: $SYSTEM.CSSnn.C1097P00 for direct-connect lines $SYSTEM.CSSnn.C1098P00 for satellite-connect lines

Units: Not applicable Range: 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)


Expand Modifiers PVCNAME n

when the line is started. For more information on the DLC tasks, see the WAN Subsystem Configuration and Management Manual.

PVCNAME n

Default: None Units: Not applicable Range: 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).

QUALITYTHRESHOLD n

Default: 98 Units: Integers Range: 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.


QUALITYTIMER n

Default: 0 Units: hh:mm:ss Range: 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.


RETRYPROBE n

Default: 19 for IP and ATM lines 10 for Expand-over-ServerNet lines 20 for Expand-over-NAM lines

Units: seconds Range: 1 through 255

This modifier specifies the number of times the Expand-over-NAM or Expand-over-ServerNet line-handler process will retry its probe of the network access method


Expand Modifiers RSIZE n

(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-over-ATM 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.

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. For more information on establishing time factors, see Setting Time Factors on page 17-23.

RXWINDOW n

Default: 7 Units: Packets Range: 2 through 15 for all line types

This modifier is applicable to all Expand line types.

For Expand-over-NAM and Expand-over-ServerNet 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.


Expand Modifiers SPEED n

SPEED n

Default: 0 Units: bits per second (bps) Range: 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 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

For more information on establishing time factors, see Setting Time Factors on page 17-23.

SPEEDK n

Default: none. (The value NOT_SET is displayed) Units: Kbps as integers, integers with K or M suffixes, or symbolic names Range: 1 through 4,000,000,000 and symbolic values shown in table below

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 16-2 on page 16-24.

Here are the rules for converting SPEEDK to a time factor:

if SPEEDK >= 21000 then the time factor = 1

For SPEEDK values less than 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 21000 or faster. If old profiles are used, a ServerNet line and an ATM 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). For more information on establishing time factors, see Setting Time Factors on page 17-23.


Expand Modifiers SPEEDK n

Table 16-2 shows the time-factor conversions for various SPEEDK settings:

Table 16-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 T1

2000 10

4000 5 TOKEN4

5200 4

7000 3 ETHER10

10500 2

16000 1 TOKEN16

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


Expand Modifiers SRCIPADDR n

SRCIPADDR n

Default: 0.0.0.1 Units: Not applicable Range: 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 Expand-over-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


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 Expand-over-IP line-handler process. UDP port numbers are explained in the TCP/IP Configuration and Management Manual.

STARTUP_OFF/STARTUP_ON

Default: STARTUP_OFF Units: Not applicable Range: 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: SUPERPATH_OFF Units: Not applicable Range: ON or OFF

These modifiers apply to all Expand line types except for Expand-over-ServerNet. 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. The Expand


Expand Modifiers TIMERINACTIVITY n

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 32 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 line-handler processes that are part of a multi-CPU path. For more information on congestion control, see L4CONGCTRL_OFF/L4CONGCTRL_ON on page 16-13. For more information on the extended packet format, see L4EXTPACKETS_OFF/L4EXTPACKETS_ON on page 16-14.

The Expand multi-CPU feature is described in detail in Multi-CPU Feature on page 17-72.

TIMERINACTIVITY n

Default: 900 for Expand-over-X.25 and Expand-over-SNA lines 0 (no timer) for Expand-over-IP

Units: seconds Range: 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 Expand-over-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: 1 for Expand-over-IP and Expand-over-ATM 300 for Expand-over-X.25 and Expand-over-SNA 30 for Expand-over-ServerNet

Units: seconds Range: 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-ServerNet


Expand Modifiers TIMERRECONNECT n

This specifies time interval that the Expand-over-NAM or Expand-over-ServerNet 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 Expand-over-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 14-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-ATM, or Expand-over-IP line-handler process declares the network unavailable.

See also RETRYPROBE n and TIMERRECONNECT n.

TIMERRECONNECT n

Default: 30 for Expand-over-IP, Expand-over-ATM, and Expand-over-NAM 5 for Expand-over-ServerNet

Units: seconds Range: 30 through 32767 for Expand-over-IP, Expand-over-ATM

0 through 32767 for Expand-over-NAM and Expand-over-ServerNet

This specifies the time interval that the Expand-over-NAM, Expand-over-ATM, Expand-over-IP, or Expand-over-ServerNet 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 14-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: 18 for satellite-connect lines 4 for all Expand-over-NAM lines

7 for all other line types Units: Packets Range: 2 through 7 for Expand-over-X.25, 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.

For Expand-over-NAM and Expand-over-ServerNet line-handler processes, this modifier specifies the number of packets that the Expand line-handler process can


Expand Modifiers V6DESTIPADDR n

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 this 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, although 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: 0000:0000:0000:0000:0000:0000:0000:0000 Units: Not applicable Range: 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 Modifiers V6SRCIPADDR n

V6SRCIPADDR n

Default: 0000:0000:0000:0000:0000:0000:0000:0000 Units: Not applicable Range: 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.

ProfilesThis subsection lists the modifiers that are contained in each of the profiles.

Single-Line Expand Line-Handler Process Modifiers

Table 16-3 lists the modifiers in the profiles provided for single-line Expand line-handler processes.

Table 16-3. Single-Line Path Modifiers (page 1 of 4)

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 Modifiers Single-Line Expand Line-Handler Process Modifiers

CLOCKSPEED_4800 X X

CLOCKSPEED_9600 X X

CLOCKSPEED_19200 X X




COMPRESS_OFF X X X X X X X

COMPRESS_ON 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_OFF

X X X X

DOWNIFBADQUALITY_ON

X 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

IPVER_IPV4 X

IPVER_IPV6 X


X X

L2DISCARDONRESET_ON

X X

L2RETRIES X X X X X X X

L2TIMEOUT X X

L4CONGCTRL_OFF X X X X X X X

L4CONGCTRL_ON X X X X X X X

L4CWNDCLAMP X X X X X X X




Expand Modifiers Single-Line Expand Line-Handler Process Modifiers

L4EXTPACKETS_OFF X X X X X X X

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

MAXRECONNECTS X X X X X

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

RETRYPROBE X X X X X

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 X

TIMERPROBE X X X X X

TIMERRECONNECT X X X X X




Expand Modifiers Multi-Line Path Modifiers

Multi-Line Path Modifiers

These modifiers are included in the PEXPPATH profile provided for path logical devices:

• COMPRESS_OFF• COMPRESS_ON• L4CONGCTRL_OFF• L4CONGCTRL_ON• L4CWNDCLAMP• L4EXTPACKETS_OFF• L4EXTPACKETS_ON• L4RETRIES• L4SENDWINDOW• L4TIMEOUT• NEXTSYS• OSSPACE• OSTIMEOUT• PATHBLOCKBYTES• PATHPACKETBYTES• PATHTF• SUPERPATH_OFF• SUPERPATH_ON

Table 16-4 lists the modifiers in the profiles provided for line-logical devices.

TXWINDOW X X X X X X X

V6DESTIPADDR X

V6SRCIPADDR X

Table 16-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




CLOCKSPEED_115200

CONNECTTYPE_ ACTIVEANDPASSIVE

X X X

CONNECTTYPE_PASSIVE X X X

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 X

INTERFACE_RS232 X X

INTERFACE_RS422 X X

IPVER_IPV4 X

IPVER_IPV6 X

L2DISCARDONRESET_OFF X X

L2DISCARDONRESET_ON X X

L2RETRIES X X X X X

L2TIMEOUT X X

LIFNAME X

LINEPRIORITY X X X X X

LINETF X X X X X

MAXRECONNECTS X X X





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

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

TXWINDOW X X X X X

V6DESTIPADDR X

V6SRCIPADDR X




17 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 Subsystem Components on page 17-2

• Expand Subsystem and the OSI Reference Model on page 17-9

• Path Function of the Expand Subsystem on page 17-13

• Routing and Time Factors on page 17-22

• Message Handling and Buffer Allocation on page 17-38

• Message Buffering on page 17-46

• Expand-to-NAM Interface on page 17-49

• Expand-to-IP Interface on page 17-53

• Expand-to-ATM Interface on page 17-58

• Multipacket Frame Feature on page 17-63

• Variable Packet Size Feature on page 17-67

• Congestion Control Feature on page 17-69

• Multi-CPU Feature on page 17-72


Subsystem Description Expand Subsystem Components

Expand Subsystem ComponentsThe Expand subsystem comprises these major components:

• Expand Line-Handler Processes on page 17-2

• Network Control Process ($NCP) on page 17-6

• Expand Manager Process ($ZEXP) on page 17-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 17-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, or a ServerNet monitor process ($ZZSCL), 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.


Subsystem Description Expand Line-Handler Processes

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.

Expand Line-Handler Process Types

Expand line-handler processes can be categorized as:

• Those that contain all the protocol levels necessary to perform both path and line functions. These types of Expand line-handler processes include:

° Direct-connect

° Satellite-connect

• Those that require another type of process to perform line functions. These types of Expand line-handler processes include:

° Expand-over-NAM

° Expand-over-IP

° Expand-over-ServerNet

° Expand-over-ATM

The different types of Expand line-handler processes are described in these subsections. For more information on how to configure Expand line-handler processes, see 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.

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.

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 17-9.



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.

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 line-handler 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

• 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

Note. For more information on the Expand-to-NAM interface, see Expand-to-NAM Interface on page 17-49.



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) in addition to 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.

Expand-Over-ServerNet Line-Handler Process

The Expand-over-ServerNet line-handler process uses a pair of NonStop cluster switches, processor switches, plug-in cards (PICs), fiber-optic 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 on the cluster switches, see the ServerNet Cluster Manual.

Each switch connects to two processor switches 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-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 on the Expand-to-IP interface, see Expand-to-IP Interface on page 17-53.


Note. For more information on the Expand-to-NAM interface, see Expand-to-NAM Interface on page 17-49.


Subsystem Description Network Control Process ($NCP)

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-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 an Integrity NonStop NS-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 line-handler process uses the services provided by the ATM subsystem to transmit data across an ATM network.

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 operating system.

Network Control Process Functions

The network control process, $NCP, is responsible for these 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 line-handler processes respond by aborting pending requests.

• Grouping Expand line-handler processes in a multi-CPU path to a particular neighbor node.

Note. For more information on the Expand-to-ATM interface, see Expand-to-ATM Interface on page 17-58.


Subsystem Description Expand Manager Process ($ZEXP)

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 line-handler processes to the appropriate user.

Note. The SCF interface to the Expand subsystem is described in Section 14, Subsystem Control Facility (SCF) Commands.


Subsystem Description Components Summary

Components Summary

Figure 17-1 illustrates an Expand network environment.

Figure 17-1. Expand Network Environment

VST010.vsd

Kernel

Expand

$ZNUP

$NCP

$ZEXP

FileSystem

RequesterApplication

MessageSystem

ServerApplication

Kernel

Expand

$ZNUP

$NCP

$ZEXP

FileSystem

RequesterApplication

MessageSystem

ServerApplication

Expand Line-HandlerProcess

Node \A Node \B



Subsystem Description Expand Subsystem and the OSI Reference Model

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 these topics:

• Expand Line-Handler Process Layer Functions on page 17-10

• $NCP Layer Functions on page 17-12

Figure 17-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 this discussion as a common point of reference to help explain the functions of the various layers of the Expand subsystem.

Figure 17-2. Expand Subsystem Protocol Layers

VST011.vsd

Application Layer (7)

Presentation Layer (6)

Session Layer

Transport Layer (4)

Network Layer (3)

Data Link Layer (2)

Physical Layer (1)

User Applications

Message and FileSystems

$NCP

CommunicationsHardware


Expand OSI Layers


Subsystem Description Expand Line-Handler Process Layer Functions

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.

These 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.

These 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.

These 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.


Subsystem Description Expand Line-Handler Process Layer Functions

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 these 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.

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 End-to-End protocol is described in Path Function of the Expand Subsystem on page 17-13.


Subsystem Description $NCP Layer Functions

$NCP Layer Functions

As shown in Figure 17-2 on page 17-9, $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 these 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


Subsystem Description Path Function of the Expand Subsystem

Path Function of the Expand SubsystemThis 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 End-to-End protocol provide the path function of the Expand subsystem.


• Protocol Packet Types on page 17-13

• Packet Synchronization on page 17-16

• Example of End-to-End Protocol Packet Exchanges on page 17-16

• Layer 4 Send Window on page 17-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.

Protocol Packet Types

The End-to-End protocol defines these 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.

Note. This subsection does not describe the protocols used by Expand line-handler processes at the OSI Data Link Layer (Layer 2). For more information regarding standards such as HDLC and X.25, see the documentation provided for these standards.


Subsystem Description Protocol Packet Types

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.

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 line-handler 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 might 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 line-handler processes over an open communications path.

A single reply message might 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. After all the LCMPs have been received, the buffer is deallocated.

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.


Subsystem Description Protocol Packet Types

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 line-handler 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 this 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.

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 line-handler process to another Expand line-handler process in response to a PCHG CMD packet.

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 16, Expand Modifiers.


Subsystem Description Packet Synchronization

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 multi-CPU path. For more information on PING messages, see Calculating Route Time Factors on page 17-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 17-3 on page 17-17, 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 17-4 on page 17-18 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 17-5 on page 17-19 shows an example of ENQ sequence numbering.

Example of End-to-End Protocol Packet Exchanges

Figure 17-3 on page 17-17, Figure 17-4 on page 17-18, Figure 17-5 on page 17-19, and Figure 17-6 on page 17-20 illustrate four different End-to-End protocol packet exchanges. Figure 17-3 on page 17-17 shows an error-free exchange of data; the remaining figures illustrate how the protocol recovers from problem situations.


Subsystem Description Example of End-to-End Protocol Packet Exchanges

Normal Data Exchange

Figure 17-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 can not be seen if other data packets are being transmitted.

Figure 17-3. Normal Exchange

VST012.vsd

LRQ (0)

LRQ (1)

ACK (2)

LCMP (0)

LCMP (1)ACK (2)

NODE \A NODE \B



Data Exchange With Lost Data

Figure 17-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.

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.

Figure 17-4. Lost Data

VST013.vsd

LRQ (0)

LRQ (1)

LRQ (2)

NAK (1)

NODE \A NODE \B

Lostpacket

ACK (3)

LCMP (0)

LCMP (1)

LCMP (2)ACK (3)

LRQ (1)

LRQ (2)

Out-of-sequence (OOS) timeout period



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.

Data Exchange With Lost Acknowledgment

Figure 17-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.

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.

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 16, Expand Modifiers.

Figure 17-5. Lost Acknowledgment

VST035.vsd

LRQ (0)

LRQ (1)

LRQ (2)

NODE \A NODE \B

Lost packet

ACK (3)

LCMP (0)

LCMP (1)

LCMP (2)ACK (3)

ENQ (3)

ACK (3)

(L4TIMEOUT)



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 17-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.

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.

Figure 17-6. Buffer Pool Failure

Note. The OOS buffer and the buffer pool are described in Message Handling and Buffer Allocation on page 17-38 and Message Buffering on page 17-46.

VST036.vsd

LRQ (0)

ACK (1), WAIT BIT RESET

NODE \A NODE \B

ACK (4)

LCMP (0)

LCMP (1)

LCMP (2)ACK (3)

NAK (0), WAIT

LCMP(0)(no buffer)

(to prior requestfrom NODE \B)

(buffer deallocated)LRQ (1)

LRQ (2)

LRQ (3)


Subsystem Description Layer 4 Send Window

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-to-end connection.

Note. You can alter the size of the Layer 4 send window with the L4SENDWINDOW modifier. This modifier is explained in Section 16, Expand Modifiers.


Subsystem Description Routing and Time Factors

Routing and Time FactorsThis subsection explains how $NCP implements its routing scheme. It describes these topics:

• Setting Time Factors on page 17-23

• Negotiating Path Time Factors on page 17-24

• Best-Path Route Selection on page 17-24

• Network Routing Table (NRT) and Multiple Path Table (MPT) on page 17-25

• Calculating Route Time Factors on page 17-27

• Routing Algorithms on page 17-28

• Multi-CPU Paths on page 17-31

• Multi-CPU Routing Examples on page 17-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:

• 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 (the ROUND function rounds to the nearest integer):

PATHTF = ROUND(224000 / (224000 / LINETF1 + 224000 / LINETF2 + …))


Subsystem Description Setting Time Factors

• 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 and ATM as the second best path, then you would set the PATHTF as 1 for ServerNet, 2 for ATM, and a value greater than 2 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 (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 can still be used but is not recommended. If you use this setting, every line equivalent to or faster than a SPEEDK of 21000 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.


Subsystem Description Negotiating Path Time Factors

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 can 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 this criteria to select the best-path route to a specific node:

• The route must have the lowest TF of all possible routes.


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 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 line-handler pairs. For more information on pairing, see Multi-CPU Paths on page 17-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.


Subsystem Description Network Routing Table (NRT) and Multiple Path Table (MPT)

$NCP sends routing information to the $NCPs at its neighbor nodes at these 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 17-27.)

Immediate Network Updates

If the communications line between nodes \C and \D in Figure 17-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 17-7. $NCP Exchange of Network Change Information

VST017.vsd

Node \A

Node \C

Node \B

Node \D Node \E

InformsNeighborof Failure



Line Failure InformsNeighborof Failure


Subsystem Description Calculating Route Time Factors

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.

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 17-8 shows a simple five-node 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).

Note. The AUTOMATICMAPTIMER modifier is explained in Section 6, Configuring the Network Control Process.

Figure 17-8. Sample Network With Time Factors

VST016.vsd

TF 4

TF 1 TF 1

TF 1

Node \A

Node \C

TF 1

Node \B

Node \D Node \E


Subsystem Description Routing Algorithms

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.

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 17-9 on page 17-29 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 17-30.)

The disadvantage of the MSH algorithm is that the network might experience temporary discontinuity, which occurs because $NCPs are not immediately aware of alternate paths that can 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, these 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 might 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. ALGORITHM 0 specifies MSH, and ALGORITHM 1 specifies SH. The ALGORITHM modifier is explained in Section 6, Configuring the Network Control Process.

Note. The ABORTTIMER modifier is explained in more detail in Section 6, Configuring the Network Control Process.



Figure 17-9. Routing Information With the MSH Algorithm

VST018.vsd

2 (2)

1 (1)

1 (1)

1 (1)

--

-- --

-- --

--

-- --

Node \A Node \B

Node \C Node \E

TF 4

TF 1 TF 1

TF 1 TF 1

\C \B \EVia Nodes

\A

\B

\C

\E

ToNodes

NRT

Node \D



Split Horizon (SH)

When the split horizon (SH) algorithm is used, $NCP tells its neighbor $NCP the best-path 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 17-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.

The advantage of the SH algorithm is that alternate paths are immediately known (temporary discontinuity never occurs).

Figure 17-10. Routing Information With the SH Algorithm

VST019.vsd

Node \A

TF 4

TF 1 TF 1

TF 1 TF 1

\C \B \E

\A

\B

\C

\E

NRT

2 (2)

1 (1)

1 (1)

1 (1)

6 (3)

5 (2) --

6 (3) --

--

8 (5) 8 (5)

Node \B

Node \C Node \ENode \D

ToNodes

Via Nodes


Subsystem Description Multi-CPU Paths

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 17-10 on page 17-30, 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 this 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.

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).

Note. The NETWORKDIAMETER modifier is explained in more detail in Section 6, Configuring the Network Control Process.



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 can use a different Expand line-handler pair.

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.

Note. $NCP does not know which Expand line-handler processes have been paired; this information is maintained separately in each processor in its MPT.



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 load-factor 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 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 these times:

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.


Subsystem Description Multi-CPU Routing Examples

• 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.)

• If a path is revived after being down for a defined amount of time.

Multi-CPU Routing Examples

The routing decisions made for multi-CPU paths depend on each possible combination of source and destination node; Figure 17-11 on page 17-35 shows multi-CPU routing for these combinations.



In Figure 17-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.

Figure 17-11. Network Containing Normal Paths and Multi-CPU Paths

VST053.vsd

CPU 0

CPU 1

CPU 2CPU 0

CPU 1

CPU 2

CPU 0

CPU 2

LHLH

LH

LH LH

CPU 3

LH LH

CPU 1

CPU 2CPU 0

LH

LH

CPU 0 CPU 1

CPU 2

CPU 3

LH LH

LH

CPU 1

LH

PRCA

CPU 0

CPU 1

CPU 2

CPU 4CPU 3

LH

LH

LH LH

LH

PRCB

PRCF

PRCC

Multi-CPU Path 1

Multi-CPU Path 2

Node \A

Node \B

Node \C

Node \D

Node \ENode \F



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 17-11 on page 17-35, if the process named PRCB on node \B sends a message to the process named PRCC on node \C and $NCP determines that multi-CPU path 1 is the best-path route, the NRT in processor 0 selects the Expand line-handler 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 line-handler 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 non-neighbor 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 17-11 on page 17-35, 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



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 17-11 on page 17-35, 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 must be established.

For example, in Figure 17-11 on page 17-35, if the process named PRCA on node \A sends a message to the process named PRCF on node \F and $NCP determines that the best-path 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.


Subsystem Description Message Handling and Buffer Allocation

Message Handling and Buffer AllocationThis 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.


• Outgoing Traffic Flow on page 17-38

• Incoming Traffic Flow on page 17-42

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).

Note. This subsection refers to modifiers that allow you to control message handling and buffer allocation. For more information on these modifiers, see Section 16, Expand Modifiers.


Subsystem Description Outgoing Traffic Flow

Locally Originated Traffic Flow

Figure 17-12 illustrates the path of a locally originated outgoing message.

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

Figure 17-12. Flow of an Outgoing Local Message

VST020.vsd

* Security processing* Data compression* Message prioritization

Queue message topending list fordestination node

Use memory from bufferpool and queue messageto outgoing message list

Select highest prioritymessage and format

packets

Send packets

Queue message to waitfor end-to-end ACK list

Queue messageto wait for reply list

Release bufferpool

RepliesRequests



password exists for the destination node, the request is completed with an error (file-system error 48, security violation) and is not sent.

If the COMPRESS_ON modifier is set, the Expand line-handler process tries 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.

After 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.

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.

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 might 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 17-41.)

When all the packets that make up the total message have been sent, the Expand line-handler 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.

Note. The Expand line-handler process buffer pool is explained in Message Buffering on page 17-46.

Note. The Expand line-handler process obtains packet-size information from the value assigned to the FRAMESIZE or PATHPACKETBYTES modifier.



$NCP and Passthrough Traffic Flow

Figure 17-13 illustrates the path of outgoing $NCP and passthrough traffic.

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 line-handler 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.

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 17-13.

Figure 17-13. Flow of Outgoing $NCP and Passthrough Traffic

VST021.vsd

Queue packets to$NCP/pass-through pending

list for destination node

Use memory from bufferpool and queue packets to

outgoing $NCP/pass-through packets list

Send packets

Release bufferpool


Subsystem Description Incoming Traffic Flow

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.

When they are transmitted, $NCP and passthrough packets are given precedence over locally originated traffic and can 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.

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 17-14 on page 17-43 illustrates the paths of different types of incoming traffic.

Note. $NCP obtains packet size information from the value assigned to the network control process FRAMESIZE modifier.

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.



As shown in Figure 17-14, the Expand line-handler process manages different types of incoming packets differently. These subsections describe each type of packet and explain how each is processed by the Expand line-handler process.

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.

Figure 17-14. Flow of Incoming Packets

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 17-47.

VST022.vsd

Use OOSbuffer space

Reserve memoryfrom buffer pool

for total message

Match reply torequest and placein request buffer

pool space

Use memory frombuffer pool for

packet

Out-of-sequencepacket Request packet Reply packet

Check OOS bufferfor out-of-sequencepackets

Route packet tooutgoing

process of local$NCP

Reassemble messagewhen all packets

are received

* Decompress data* Checksum

* Decompress data* Checksum* Security processing

Route messageto server andrelease buffer

pool space

Route messageto requester and

release bufferpool space

Requests Replies

$NCP/passthroughpacket



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.

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.

After 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.

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.

Note. LRQs are also described in Protocol Packet Types on page 17-13.

Note. LCMPs are also described in Protocol Packet Types on page 17-13.



After 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.

After the packet has been routed to the appropriate process ($NCP or Expand line-handler), the Expand line-handler process releases the buffer pool used by the packet.

Note. For more information on outgoing $NCP and passthrough packet handling, see $NCP and Passthrough Traffic Flow on page 17-41.


Subsystem Description Message Buffering

Message BufferingThe 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.


• Global Variables on page 17-47

• Stack on page 17-47

• Control Blocks on page 17-47

• Line Buffer on page 17-47

• Buffer Pool on page 17-47

• Shared Memory Area for QIO on page 17-48

Figure 17-15 illustrates the Expand line-handler process data space.

Note. This subsection refers to modifiers that allow you to control message buffering. For more information on these modifiers, see Section 16, Expand Modifiers.

Figure 17-15. Expand Line-Handler Process Data Space

VST023.vsd

Shared MemoryArea for QIO

GlobalVariables

Stacks

ControlBlocks

OOS Buffer

LineBuffer

BufferPool

Pool Space


Subsystem Description Global Variables

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 Expand-over-NAM and Expand-over-ServerNet 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.

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 17-13 on page 17-41, Figure 17-14 on page 17-43, and Figure 17-15 on page 17-46 show when the buffer pool is used.

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.


Subsystem Description Shared Memory Area for QIO

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.

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 NonStop TCP/IPv6 but also imposes constraints that affect all QIO clients (including NonStop TCP/IPv6). As discussed in the QIO Configuration and Management Manual, you must consider these constraints in addition to a variety of other factors before changing the default QIO configuration.

Some of the constraints affecting NonStop TCP/IPv6 (in addition to 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 cannot be sufficient for your NonStop TCP/IPv6 or other QIO client needs.


Note. QIO memory is not the same as Extended Memory. Expand-over-ATM and Expand-over-IP have both QIO and Extended Memory requirements.

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 NonStop TCP/IPv6; all changes are made in the QIO subsystem.


Subsystem Description Expand-to-NAM Interface

Expand-to-NAM InterfaceThis subsection describes how Expand-over-NAM and Expand-over-ServerNet 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, or ServerNet connections.

Topics described in this subsection include:

• Network Access Method (NAM) Processes on page 17-49

• Connection Establishment on page 17-50

• Sending and Receiving Data on page 17-52

You should be familiar with the information in Expand Line-Handler Processes on page 17-2, Expand Subsystem and the OSI Reference Model on page 17-9, and Message Handling and Buffer Allocation on page 17-38 before reading this subsection.

Network Access Method (NAM) Processes

Expand-over-NAM line-handler processes (which include Expand-over-X.25 and Expand-over-SNA), and Expand-over-ServerNet 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 these type of Expand line-handler process:

• 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-NAM and Expand-over-ServerNet line-handler processes use the NETNAM protocol to communicate with the NAM interface of the NAM process that provides Layer 2 services.

Note. This subsection refers to modifiers that allow you to control various aspects of the Expand-to-NAM interface. For more information on these modifiers, see Section 16, Expand Modifiers.


Subsystem Description Connection Establishment

Connection Establishment

Figure 17-16 illustrates the events that occur when Expand-over-NAM and Expand-over-ServerNet line-handler processes successfully establish a connection through a NAM interface.

Bind Requests and Subdevices

Before an Expand-over-NAM or Expand-over-ServerNet line-handler process can begin exchanging data with another Expand line-handler process, it must first access a subdevice of the NAM process.

Figure 17-16. Expand-Over-NAM Connection Establishment

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.

Active and Passive Connect Type Passive Connect Type

024VST

Expand line-handler process

can send andreceive data

Connectionestablished

Connectionestablished

NAM receivesconnectrequest

Expand line-handlerprocess sendsactive connect

Expand line-handlerprocess sends

passive connect

Expand line-handler process

sends bindrequest


Subsystem Description Connection Establishment

The Expand-over-NAM or Expand-over-ServerNet 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 or Expand-over-ServerNet 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 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-over-NAM or Expand-over-ServerNet 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.)

After the Expand-over-NAM or Expand-over-ServerNet line-handler process has successfully bound to a subdevice, it tries to establish a connection through the NAM process to a neighbor Expand line-handler process. There are two ways the Expand-over-NAM or Expand-over-ServerNet 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 or Expand-over-ServerNet line-handler process to use the active connect method by specifying the CONNECTTYPE_ACTIVEANDPASSIVE modifier.

Active Connect Request

When the Expand-over-NAM or Expand-over-ServerNet line-handler process issues an active connect request, the NAM process tries to initiate a connection. If the request is successful, the Expand-over-NAM or Expand-over-ServerNet 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 or Expand-over-ServerNet 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 Expand-over-NAM or Expand-over-ServerNet line-handler process.

If the passive connect request is not successful within the timeout period, the Expand-over-NAM or Expand-over-ServerNet 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 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 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 or Expand-over-ServerNet line-handler process will attempt a


Subsystem Description Sending and Receiving Data

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 or Expand-over-ServerNet line-handler 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. After the passive connect request is successful, the Expand-over-NAM or Expand-over-ServerNet line-handler process can begin sending and receiving data over the connection.

If the connection request is not successful within the timeout period, the Expand-over-NAM or Expand-over-ServerNet 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 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 or Expand-over-ServerNet 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 or Expand-over-ServerNet 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 or Expand-over-ServerNet line-handler process before requiring acknowledgment by specifying the RXWINDOW modifier.

After a connection is established, the Expand-over-NAM or Expand-over-ServerNet 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.


Subsystem Description Expand-to-IP Interface

Expand-to-IP InterfaceThis 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 17-53

• Expand-over-IP Connection Establishment on page 17-54


• Forwarding Expand-over-IP Packets to Other Expand Line-Handler Processes on page 17-56

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 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 or TCP6SAM process.

NonStop TCP/IP and TCP6SAM processes provide a Guardian file-system interface to the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) in addition to raw (direct) access to the Internet Protocol (IP). (However, raw-socket support is limited with the NonStop TCP/IPv6 subsystem. For more information on the raw-socket programming limitations, see the TCP/IP and TCP/IPv6 Programming Manual. 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 that provides a mechanism for identifying the ultimate destination in a host, such as an application program or other high-level process.

Note. This subsection refers to modifiers that allow you to control various aspects of the Expand-to-IP interface. For more information on these modifiers, see Section 16, Expand Modifiers.

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 TCP/IPv6 architecture removes this restriction, so when the NonStop TCP/IPv6 subsystem is used for TCP/IP connectivity, the Expand-over-IP line-handler process does not need to reside in the same processor pair as the TCP6SAM 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.


Subsystem Description Expand-over-IP Connection Establishment

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.

NonStop TCP/IPv6 provide a feature called single IP which allows a single 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 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 or TCP6SAM process.

After the Expand-over-IP line-handler process has successfully bound to the NonStop TCP/IP or TCP6SAM process, it tries 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 line-handler process to use the active connect method by specifying the CONNECTTYPE_ACTIVEANDPASSIVE modifier.


When the Expand-over-IP line-handler process issues an active connect request, it tries to initiate a connection by sending a Connect Command frame 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

Note. Because UDP is a connectionless protocol, there is no actual connection to the remote Expand-over-IP line-handler process.


Subsystem Description Expand-over-IP Connection Establishment

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 line-handler 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.


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 line-handler process. You can cause the Expand-over-IP 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-IP line-handler process receives a Connect Command within the connect timeout period. After 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-over-IP 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 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.

Note. Because UDP is a connectionless protocol, there is no actual connection to the remote Expand-over-IP line-handler process.




After a connection has been established, the local and remote Expand-over-IP line-handler processes communicate through their associated NonStop TCP/IP 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.

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 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-IP line-handler process will retry Probe messages with the Expand SCF RETRYPROBE attribute.

Forwarding Expand-over-IP Packets to Other Expand Line-Handler 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 17-17 on page 17-57 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.

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 NonStop TCP/IPv6 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.


Subsystem Description Forwarding Expand-over-IP Packets to Other Expand Line-Handler Processes

Figure 17-17. Expand-Over-IP Packet Forwarding

VST034.vsd

IPNetwork

Node 1

Application

MessageSystem

Expand Line-Handler Process

TCP/IP Process

Node 3

Application

MessageSystem

ExpandLine-Handler

Process

Node 2

MessageSystem

ExpandLine-Handler

Process


TCP/IP Process

Direct-ConnectConnection


Subsystem Description Expand-to-ATM Interface

Expand-to-ATM InterfaceThis 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 17-58

• Expand-over-ATM Connection Establishment on page 17-59


• Forwarding Expand-over-ATM Packets to Other Expand Line-Handler Processes on page 17-62

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 an Integrity NonStop NS-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.

Note. This subsection refers to modifiers that allow you to control various aspects of the Expand-to-ATM interface. For more information on these modifiers, see Section 16, Expand Modifiers.


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 these information:

• The ATM address configured for the ATM line used by the remote Expand-over-ATM 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.

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 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.

After the Expand-over-ATM line-handler process has successfully bound to the ATM line, it tries 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.

Note. Selector bytes must be coordinated among ATM clients using the same ATM line.


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.


When the Expand-over-ATM line-handler process issues an active connect request, it tries 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 line-handler 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.


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. After 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-over-ATM 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



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.


After a connection has been established, the local and remote Expand-over-ATM line-handler 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.

To detect loss of connection through the ATM network, the Expand-over-ATM line-handler 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.

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-over-ATM 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.


Subsystem Description Forwarding Expand-over-ATM Packets to Other Expand Line-Handler Processes

Forwarding Expand-over-ATM Packets to Other Expand Line-Handler 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 17-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 17-18. Expand-Over-ATM Packet Forwarding

VST057.vsd

ATM Network

Node 1

Application

Message

Expand Line-Handler Process

ATM Subsystem

Node 3

Application

Message


Node 2

Message

ExpandLine-Handler

Process


ATM Subsystem

Direct-ConnectConnection


Subsystem Description Multipacket Frame Feature

Multipacket Frame FeatureThe 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 these topics:

• Constructing Multipacket Frames on page 17-63

• Path Initialization on page 17-65

• Multipacket Frame Configuration on page 17-66

• Multipacket Frame Considerations on page 17-66

Before reading this subsection, you should be familiar with the material presented in the subsection Expand-to-NAM Interface on page 17-49.

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 handled by the Layer 2 protocol depends on these type of Layer 2 protocol used:

• If the Layer 2 protocol is HDLC or HDLC Extended Mode, each multipacket frame is handled as a single HDLC-type frame.

• If the Layer 2 protocol is replaced by a NAM interface, such as X25AM, each multipacket frame is handled 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 handled as a separate UDP frame.

• If the Layer 2 protocol is NETATM (the protocol used by Expand-over-ATM line-handler processes), each multipacket frame is handled 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 handled by the Layer 2 protocol depends on these type of Layer 2 protocol used:

• If the Layer 2 protocol is HDLC or HDLC Extended Mode, each packet is handled as a separate HDLC-type frame.

• If the Layer 2 protocol is a NAM interface, each Expand packet is handled as a separate NAM message.

Note. For more information on the advantages and disadvantages of the multipacket frames feature, see Section 3, Planning a Network Design. For more information on how to configure this feature, see the configuration section for the type of Expand line-handler process you want to configure.


Subsystem Description Constructing Multipacket Frames

• If the Layer 2 protocol is NETIP, each Expand packet is handled as a separate UDP frame.

• If the Layer 2 protocol is NETATM, each Expand packet is handled as a separate ATM frame.

Figure 17-19 shows how Expand packets are sent over a direct-connect (HDLC) connection when the multipacket frame feature is not selected.

In Figure 17-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 17-20 on page 17-65 shows how the same message is handled when the multipacket frame feature is selected.

In Figure 17-20 on page 17-65, 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.

Figure 17-19. Multipacket Frame Feature Not Selected

VST031.vsd

Message

Direct-ConnectExpand Line-

Handler Process

1 2 3 4 5 6

HDLC-TypeFrames

ExpandPackets

61 52 3 4


Subsystem Description Path Initialization

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.

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.

Figure 17-20. Multipacket Frame Feature Selected

VST032.vsd

Message

Direct-ConnectExpand Line-

Handler Process

1 2 3 4 5 6

HDLC-TypeFrame

1 2 3 4 5 6

MultipacketFrame


Subsystem Description Multipacket Frame Configuration

Multipacket Frame Configuration

The FRAMESIZE modifier determines the maximum Expand packet size, in bytes, according to this 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.

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 16, Expand Modifiers.

Multipacket Frame Considerations

Consider these 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. After a multipacket frame is full, it is transmitted, and another line and its associated multipacket frame can be selected. Partially filled multipacket frames are transmitted if the Expand line-handler 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. The multipacket frame 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.

Note. For more configuration considerations, see Considerations for Paths Using the Variable Packet Size Feature and the Multipacket Frame Feature on page 17-69.


Subsystem Description Variable Packet Size Feature

Variable Packet Size FeatureThe 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 these topics:

• Variable Packet Size Configuration on page 17-67

• Variable Packet Size Considerations on page 17-67

• Mixing Extended and Nonextended Packets on page 17-68

• Considerations for Paths Using the Variable Packet Size Feature and the Multipacket Frame Feature on page 17-69

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 16, Expand Modifiers.

Variable Packet Size Considerations

Consider these 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.


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 line-handler 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 because 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 17-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 17-21. Mixing Extended and Nonextended Packets

VST033.vsd

Node \A(D30)

Node \B(D30)

Node \C(L4EXTPACKETS_OFF)

Extendedpackets

Nonextendedpackets

Nonextendedpackets


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.

Congestion Control FeatureCongestion in a network occurs when performance on a connection degrades because of the saturation of a resource that is needed to deliver data from the source to the destination. Congestion control mechanisms regulate system resources to avoid network bottleneck and resource contention situations.


• Congestion Control Configuration on page 17-71

• Congestion Control Considerations on page 17-71

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 to support it.

In Figure 17-22 on page 17-70, 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.

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.


Subsystem Description Congestion Control Feature

Nodes that support congestion control are compatible with nodes that do not. However, connections between such nodes will not use congestion control. In Figure 17-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 17-22. Congestion Control Not Enabled

Figure 17-23. Congestion Control Not Supported

VST014.vsd

On

OnOff

Off

Congestion Control On

Congestion Control On

L4CONGCTRL_ON L4CONGCTRL_OFF L4CONGCTRL_ON

Node \A Node \B Node \C

VST015.vsd

Congestion control on

Congestion control on

L4CONGCTRL_ON L4CONGCTRL_ON

Notsupported

NotsupportedOff

Off

Congestion control notsupported



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. You can also configure the congestion control transmit window using the L4CWNDCLAMP modifier. The default is L4CONGCTRL_ON for Expand-over-IP line-handler 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 can be retransmitted, increasing the network traffic and congestion. Because congestion is already being experienced on the network, it is likely that the retransmission will also cause lost packets, so the whole retransmission sequence continues, drastically decreasing throughput.


Subsystem Description Multi-CPU Feature

Multi-CPU FeatureThe 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:

• Multi-CPU Paths on page 17-72

• Multi-CPU Configuration on page 17-72

• Multi-CPU Considerations on page 17-73

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.

One Expand line-handler process at each source node and one Expand line-handler process at each destination node are paired to guarantee message order; all messages between that source and destination node are sent through this Expand line-handler pair.

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.

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

Note. For more information on the Expand-over-IP line-handler processes, see Expand-to-IP Interface on page 17-53.

Note. For more information on the formation about Expand line-handler pairs, see Multi-CPU Paths on page 17-31.

Note. The SUPERPATH_ON and SUPERPATH_OFF modifiers are described in detail in Section 16, Expand Modifiers.


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 line-handler 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 these when configuring the Expand multi-CPU feature:

• You cannot configure more than 32 multi-CPU paths in a system.

• Each multi-CPU path can consist of up to 16 paths.

• Expand-over-ServerNet 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 cause 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 on configuring extended packets, see L4EXTPACKETS_OFF/L4EXTPACKETS_ON on page 16-14. For more information on configuring the congestion control feature, see Congestion Control Feature on page 17-69.


Subsystem Description Multi-CPU Considerations



Part V consists of these sections, which provide management, tuning, and troubleshooting information:

Section 18 Managing the Network

Section 19 Tuning

Section 20 Troubleshooting


18 Managing the Network

This section explains how to access network resources, set up network security, and monitor, reconfigure, and control an Expand network.

• Accessing Network Resources on page 18-1• Setting Up Network Security on page 18-7• Monitoring Network Activity on page 18-13• Reconfiguring the Network on page 18-20• Controlling the Network on page 18-26

For more information on the commands described in this section, see:

• For Expand Subsystem Control Facility (SCF) commands, see Section 14, Subsystem Control Facility (SCF) Commands.

• For WAN subsystem SCF commands, see the WAN Subsystem Configuration and Management Manual.

• For Kernel subsystem SCF commands, see the SCF Reference Manual for the Kernel Subsystem.

• For general SCF commands, see the SCF Reference Manual for H-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, see Appendix B, Expand and WAN SCF Comparison.

Accessing Network ResourcesThis 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:

• Using TACL to Manage Remote Files on page 18-2• Using Disk-File Names on page 18-2• Changing Your Default Values on page 18-3• Gaining Access to Remote Nodes on page 18-4


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.

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.

These are examples of partially qualified file names:

This 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.

Note. Selected TACL commands are described in this subsection. For the syntax and refer-ence information about all TACL commands and programs, see the TACL Reference Manual.

FERN.HERST SUBVOL2.FILEA

HERST FILENAME


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.

VOLUME Command

You can use the VOLUME command to change your current default node, volume, or subvolume. This 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 this:

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.

This 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.

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 recog-nize 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.


Managing the Network Gaining Access to Remote Nodes

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 this example, the local node is \MEL and the current node is a remote node named \STU.

Gaining Access to Remote Nodes

When Integrity NonStop NS-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.

Starting and Quitting a Remote TACL Process

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

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 18-4.

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”

Note. Safeguard can secure a file so that only specific individuals can access that file. For more information on the Safeguard, see the Safeguard Administrator’s Manual.

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 18-7.



is part of a network that includes the \HERST node, you can start a TACL process on \HERST by entering this 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 this command instead of the previous command:

\HERST.TACL / NAME, CPU 1 / 2

The NonStop 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:

\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, these 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.

For example, to run a program named MYPROG on the remote node \CITY using an explicit RUN command, you would type this command:

RUN \CITY.MYPROG

To run the same program using an implicit RUN command, you would type this 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 this 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

This 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/

Note. These examples and explanations assume that the proper network access rights are in effect.


Managing the Network Setting Up Network Security

Setting Up Network SecurityOne 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:

• Remote File Security• Remote Process Security • Remote TACL Processes• Global Remote Passwords• Subnetwork Security• Remote Super ID User• Additional Security Techniques

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 these 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 these 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. For more information on SAFECOM, see the Safeguard Administrator’s Manual.

You can verify user names and IDs with the USERS command. As shown in this 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


Managing the Network Establishing Remote Passwords

GROUP . USER I.D. # SECURITY DEFAULT VOLUMEID ADMIN .BILL 6,14 NONO $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, these commands are entered to establish an allow-access remote password to node \WEST:

logon admin.bill remotepassword \west, shazam

The allow-access password for ADMIN.BILL for \WEST from all other nodes is SHAZAM.

At node \EAST, these 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 tries 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, this 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

These 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.


Managing the Network Remote Process Security

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, after defined, remains in effect until modified by a subsequent REMOTEPASSWORD command. This command removes the remote password for the system \EAST:

remotepassword \east

This command removes all 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 this command with password LOCBILL at either system:

password locbill

Remote Process Security

These 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 these 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.


Managing the Network Remote TACL Processes

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 this 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 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 these 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


Managing the Network Subnetwork Security

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, this 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 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:

• 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 18-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.


Managing the Network Additional Security Techniques

Additional Security Techniques

The Safeguard security system extends the security offered by the NonStop operating system. Safeguard does not need to be installed on every system on the network and can be controlled by a single system. Safeguard adds these 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

• 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.


Managing the Network Monitoring Network Activity

Monitoring Network ActivityNetwork monitoring includes gathering statistical information, checking the status of hardware and software components, and displaying configuration values. This subsection is organized according to these 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 18-1 lists the Expand subsystem SCF commands that display $NCP information.

Table 18-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 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 before the introduction of Super Time Factors.


Managing the Network Displaying $NCP Information

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 in addition to the other information already in the LINESET command. It also includes all 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

or

LISTDEV TYPE 62

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.

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 18-1. Expand SCF Commands for $NCP Information (page 2 of 2)



Managing the Network Displaying Expand Line-Handler Process Information

Table 18-2 lists the WAN subsystem SCF commands that display $NCP information.

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 18-3 lists the Expand subsystem SCF commands that display general Expand line-handler process information.

When you use the SCF LISTDEV command to list all the configured Expand line-handler processes, you can use the subtype displayed to identify the type of Expand line-handler process.

Table 18-2. WAN SCF Commands for $NCP Information


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.

Table 18-3. Expand SCF Commands for Expand Line-Handler Processes


LISTDEV EXPAND

or

LISTDEV TYPE 63

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.

VERSION PROCESS $device_name Displays the version level of the Expand line-handler process.



Table 18-4 lists the subtype values associated with single-line Expand line-handler processes.

Table 18-5 lists the subtype values associated with multi-line paths (path and line logical devices).

Table 18-6 lists the WAN subsystem SCF commands that display Expand line-handler process information.

Table 18-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

Table 18-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 18-6. WAN SCF Commands for Expand Line-Handler Process Information (page 1 of 2)


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.

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.



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 line-handler process.

Table 18-7 lists the Expand subsystem SCF commands that can be used to display line information.

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 line-handler 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 line-handler 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, or ServerNet 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 18-7. Expand SCF Commands for Line Information (page 1 of 2)


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.

STATS LINE $device_name Displays Layer 2 statistics for a selected Expand line-handler 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.

Table 18-6. WAN SCF Commands for Expand Line-Handler Process Information (page 2 of 2)




Displaying Path Information

Table 18-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 line-handler process.

STATUS LINE $device_name Displays status information for a selected Expand line-handler 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.

Table 18-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 line-handler 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.

Table 18-7. Expand SCF Commands for Line Information (page 2 of 2)



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 18-9 lists the Expand subsystem SCF commands that can be used to start and stop tracing.

For more information on the tracing process and using PTrace to format and display trace records, see Section 15, Tracing.

Table 18-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.


Managing the Network Reconfiguring the Network

Reconfiguring the Network Network reconfiguration tasks include:

• 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

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 this $NCP modifier values:

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.

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).

ABORTTIMER CONNECTTIME

MAXCONNECTS MAXTIMEOUTS

NETWORKDIAMETER


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 16, 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 on profiles, see the WAN Subsystem Configuration and Management Manual.

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 line-handler process at each adjacent system for the link to the new system.

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 16, Expand Modifiers.

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.


Managing the Network Removing Nodes From the Network

Creating and starting Expand line-handler processes is explained in detail in Section II, Configuring the Expand Subsystem.

Step 2: Start the lines

After the Expand line-handler processes are created and started, you must start the communications lines using one of these Expand subsystem SCF commands:

START LINE $device_name START PATH $device_name

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 18-10.

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.

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.

Note. Before you can start an Expand line-handler process, other processes might need to be present and running in your system. For more information, see Section II, Configuring the Expand Subsystem.

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.

Table 18-10. Expand SCF Status Commands

CommandStatus 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). For more information, see the Operator Messages Manual.


Managing the Network Changing System Names and Numbers

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 these Expand subsystem SCF commands:

ABORT LINE $device_name ABORT PATH $device_name

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 18-10 on page 18-22.

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.

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, this command saves the configuration file at $SYSTEM.ZSYSCONF.CONF0101:

-> SAVE CONFIG 1.1

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.

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. For a description of the commands to use to remove node names and numbers from the NRT, see Changing System Names and Numbers.

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. For more information, see the appropriate manuals describing the alternate-key files. For example, the Open System Services Management and Operations Guide has a subsection on changing a node number.



The SCF SAVE command is described in detail in the SCF Reference Manual for G-Series 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 these Expand subsystem SCF commands:

ABORT LINE $device_name ABORT PATH $device_name

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. This is an example of a display produced by the SCF INFO SUBSYS command.

The SCF INFO SUBSYS command is described in detail in the SCF Reference Manual for the Kernel Subsystem.

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

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 multi-line path.

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 manual reload or hard reset of the system).

None



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

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.

Step 6: Perform a system load

Because the attributes that change the system name and number are stored in a SEEPROM in the Integrity NonStop NS-series server backplane, changes to them will not take effect until you perform a system load.

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) because 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.

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 manual reload or hard reset of the system).

SYSTEM_NUMBER........................ 44 SYSTEM_NAME.......................... \EAST

Note. You must perform the system load using the Start System button or the Start System command (under the Operations menu) in OSM. For more information, see the online help within OSM.


Managing the Network Controlling the Network

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, this 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.

Controlling the NetworkNetwork control tasks include:

• 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 line-handler 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.

Note. The deleted system name and/or system number might appear in the SCF INFO PROCESS $NCP, LINESET display until the node is reconnected.


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 18-11 describes each of these commands and the actions they perform.

Table 18-11. Expand SCF Control Commands


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.


Managing the Network Switching Primary and Backup Processes

Switching Primary and Backup Processes

The SCF interface to the Expand subsystem provides commands to change the primary and backup processes, Table 18-12 describes these commands.

Rebalancing Multi-CPU Paths

The SCF interface to the Expand subsystem provides commands to rebalance multi-CPU 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 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 after 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, see Load Balancing on page 19-16.

Table 18-12. Expand SCF Commands for Switching Processors


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.


19 Tuning

This section provides guidelines for improving network performance and describes the tools available for measuring performance.

• The Role of Network Tuning on page 19-1• Performance Factors on page 19-2• Measuring and Mapping an Expand Network on page 19-22• Tuning Examples on page 19-28

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.

The Role of Network TuningTuning 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

These 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).

Although 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. After 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.

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 packet-size 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.


Tuning Performance Factors

Performance FactorsThis subsection describes the factors that can be adjusted to improve Expand line-handler process performance and processor utilization. Performance factors, and their relative effect on the tuning goals described earlier in this section, are shown in Table 19-1.

How to Use the Performance Factors Table

To use Table 19-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.

The performance goals listed in Table 19-1 are described in detail in the remainder of this subsection.

Table 19-1. Performance Factors

Performance Factors

Tuning Goals

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.


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 line-handler 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

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.

Note. This 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.


Tuning Multipacket Frame Size

Figure 19-1 shows throughput gains and losses resulting from the use of multipacket frames.

Processor Use and Message Size

Multipacket frames can improve the processor efficiency of all line types. Direct-connect 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 line-handler 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 because all data is sent across only one line. For more information on the multi-line paths, see Multi-Line Paths on page 19-13.

Figure 19-1. Throughput With and Without Multipacket Frames

1600

1400

1200

0

200

400

600

800

1000

1800

132 516 744

Framesize (in words)

Single-packet Multipacket

Kilobits per second

VST074.vsd


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. For an explanation of the variable packet-size feature, see Variable Packet Size.

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 this formula:

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.

For more information on configuring the multipacket frame feature, see Multipacket Frame Feature on page 17-63.

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 these 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. Although small online transaction processing (OLTP) requests transfer fastest with smaller frame sizes,

(((txw + 1) * pathblockbytes * 8 ) / (lspd / 100) + (2 * dl) + 10

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 this command:

ALTER LINE $device_name, L2TIMEOUT 3.00


Tuning Variable Packet Size

larger bulk 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. For more information on the extended and nonextended packet formats, see Packet Format on page 19-9.

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 because all data is sent across only one line. For more information on the multi-line paths, see Multi-Line Paths on page 19-13.

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. Because 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 this formula:

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.

(((txw + 1) * pathpacketbytes * 8) / (lspd / 100)) + (2 * dl) + 10


Tuning Application Message Size

For more information on configuring the variable packet-size feature, see Variable Packet Size Feature on page 17-67.

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 19-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 QIO, defines the 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 this command:

ALTER LINE $device_name, L2TIMEOUT 3.00

Figure 19-2. Application Data Flow for Expand-Over-IP

ViaMessageSystem

Application

A

Expand

TCP/IP

Process

System \A

Application

B

Expand

TCP/IP

Process

System \B

IP Network VST073.vsd

ViaMessageSystem

Via QIO Via QIO


Tuning Application Message Size

As shown in Figure 19-2 on page 19-7, QIO 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 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 this formula:

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.

The values of fsm and pkt vary according to the oldest version of the Expand subsystem at the originating and destination nodes.

1 + $INT((app_msg + fsm) / (packet_size - pkt))


Tuning Packet Format

Packet Format

The Expand subsystem enforces a minimum value of 1024 bytes for the variable-packet 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 19-2 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.

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. For more information on the packet size and multi-line paths, see Multi-Line Paths on page 19-13.

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 line-handler 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 because of 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.

Table 19-2. Data-Per-Packet Percentages

Packet Header Format

PATHPACKETBYTES Modifier Value (Bytes)

Packet Size (Bytes)

Packet Header (Bytes)

Data Portion (Bytes)

Percentage (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.


Tuning Layer 2 Window Size

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 per-connection 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-of-sequence (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.

For more information on configuring the congestion control feature, see Congestion Control Feature on page 17-69.

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, or ServerNet).

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.

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.

Note. A small Layer 2 window size can be used to cope with poor quality lines when line efficiency is not important.


Tuning Processor Type

Processor Type

The processing power of the Integrity NonStop NS-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.

For more information on the Expand-over-NAM line-handler process configuration, see Section 10, Configuring Expand-Over-X.25 Lines and Section 13, Configuring Multi-Line 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 Expand-over-IP line-handler process.

With NonStop TCP/IPv6, the Expand line-handler process must be configured in a processor where a 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 TCP6SAM process.

For more information on the Expand-over-IP line-handler process configuration, see Section 8, Configuring Expand-Over-IP Lines.

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.


Tuning NAM Interface

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 line-handler 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 an Integrity NonStop NS-series server, this extra available processor power can allow an Expand line-handler process to drive multiple high-speed 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 handled 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.

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.


Tuning Multi-Line Paths

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 multi-line 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:

• Processor type• Packets per message• Window size• Variable packet size

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

Although 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.

For more information on the variable packet-size feature, see Variable Packet-Size Configuration on page 19-6.

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.


Tuning Multi-CPU Paths

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 because 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 use all four lines more evenly.

The general formula for configuring the variable packet size for multi-line paths using low to medium bandwidth lines is:

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 line-handler processes cannot participate as members of a Superpath.

The main advantages of the Expand multi-CPU feature include:

• Higher total throughput• More even spreading of the communications load over multiple processors• Reduced message system interprocessor traffic

PATHPACKETBYTES = average_message_size / number_of_lines



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:

• 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:

• 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.

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 in addition to 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.

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.



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 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 after 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 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 these 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.)

• 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 ACTIVATE 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.)

• If a path is revived after being down for a defined amount of time.



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 19-3 illustrates two systems that have a superpath connecting them, with a line handler on CPU 1 and CPU 3:

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.

Figure 19-3. CPU Matching

CPU 0

CPU 1

CPU 2

CPU 3

CPU 0

CPU 1

CPU 2

CPU 3

\A \B

VST008.vsd



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.

After the CPU pair has been established the 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.

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 19-4 depicts the loading for systems that are direct neighbors and are connected with a superpath, plus connections for non-neighbors:

\A and \B are connected with a superpath, \C is connected to \B, and \D connects to \C.

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 the new connections assigned to it, but they will be distributed over the superpath.

Figure 19-4. Pair Count Balancing for Neighbors and Non-Neighbors

CPU 0

CPU 1

CPU 2

CPU 3

CPU 0

CPU 1

CPU 2

CPU 3

\A \B

\C \D

VST009.vsd



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.

The \B records which line handler is used for \A's connection to \C to make sure that the correct path is used. 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.

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 load-factor 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


Tuning Network Topology

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 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 19-5.

As shown in Figure 19-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.

Figure 19-5. Passthrough Traffic

Note. The advantages and disadvantages of different network topologies are discussed in Section 3, Planning a Network Design.


$LINEB $LINEA $LINEC $LINEB

VST049.vsd


Tuning Summary of Tuning Strategies

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.

Summary of Tuning Strategies

Table 19-3 summarizes the strategies that you can use to achieve your tuning goals.

Table 19-3. 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.)


Tuning Measuring and Mapping an Expand Network

Measuring and Mapping an Expand NetworkEffective 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:

• Subsystem Control Facility (SCF). Provides a good view of long-term network behavior. The SCF interface to the Expand subsystem is described in Section 14, Subsystem Control Facility (SCF) Commands.

• Measure. Can be used to make a detailed study of a particular node’s Expand line-handler 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 Integrity NonStop NS-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 on ASAP, see these 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.


Tuning Using Measure

Using Measure

The Expand components reported on by Measure are called entities. After you have mapped your network and selected the nodes you want to measure, you can characterize the network traffic by measuring these entities:

• SYSTEM Entity• NETLINE Entity• LINE Entity• PROCESS Entity • CPU Entity

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.

Example 19-1 is an example of a SYSTEM entity display.

Note. The values shown in these diagrams are in units per second (the Measure SET REPORT RATE ON command was used).

Note. Passthrough traffic might also be referred to as forwarded or switched traffic.

Example 19-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 19-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.)

NETLINE Din4-Bytes and Dout4-Bytes counters include file-system and message-system overhead and are measured before data compression. L2in-Bytes and L2out-Bytes 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 19-3 on page 19-25, 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 19-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 1.27 Write-Busy-Time 2.21 % Writes 11.97 Read-Busy-Time 98.07 % Reads 9.34 L2in-Bytes 1,204 L2out-Bytes 1,589 Din4-Bytes 773.09 Dout4-Bytes 605.14 Cin4-Bytes 411.55 Cout4-Bytes 359.61 U64-Bytes 4.82 U128-Bytes 2.05 U256-Bytes 0.61 U512-Bytes U1024-Bytes 0.03 U2048-Bytes 0.23 U4096-Bytes 0.12 O4095-Bytes



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 the overhead of the lower layers, they do include the NonStop operating system and Expand headers and any compression words.

Example 19-4 on page 19-26 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 19-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 6.03 Retries Write-busy-Time 1.21 % Writes 11.97 Read-busy-Time 85.52 % Reads 12.08 Input-Bytes 946.94 Output-Bytes 1,548 Input-Data-Bytes 770.93 Output-Data-Bytes 1,344 Transactions Response-Time

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 line-handler 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 19-27.



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 19-5 is an example of a CPU entity display.

Example 19-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 31.20 % Ready-Time 45.73 % Mem-Qtime Dispatches 48.13 Page-Faults Vsems Pres-Pages-Qtime 315 # Pres-Pages-Max 315 # Ext-Segs-Qtime 2 # Ext-Segs-Max 2 # Recv-Qtime 0.12 Recv-Qlen-Max 8 # Messages-Sent 138.36 Messages-Received 144.37 Sent-Bytes 35,171 Received-Bytes 33,000 Returned-Bytes Reply-Bytes MQC-Allocations MQC-Alloc-Failures MQCs-Inuse-Qtime Max-MQCs-Inuse Checkpoints Alloc-Seg-Calls File-Open-Calls Info-Calls UCL-Qtime UCL-Max Accel-Busy-Time TNS-Busy-Time TNSR-Busy-Time Comp-Traps Begin-Trans Abort-Trans

Example 19-5. CPU Entity Display

Cpu 2 NSR-W Init Lock Pgs 144 Mem Pages 8192 Memory MB 128 PCBs 1800 Pg Size 16384 Bytes Local System \TAHITI From 7 Feb 1997, 12:03:32 For 43.6 Seconds

Cpu-Busy-Time 3.51 % Swaps Cpu-Qtime 0.04 # Cpu-Qlen-Max 23 # Mem-Qtime Mem-Qlen-Max 5 # Dispatches 88.91 Intr-Busy-Time 1.02 % Process-Ovhd Send-Busy-Time Disc-IOs Cache-Hits Transactions Response-Time Page-Requests Page-Scans Ending-Free-Mem 4,856 # Ending-UCME Ending-UDS 1,523 # Ending-SDS 594 # Ending-UCL 1,427 # Ending-SCL 4,294,967 K Accel-Busy-Time 0.02 % TNS-Busy-Time 0.01 % TNSR-Busy-Time 2.47 % Comp-Traps 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 this formula:

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 this values from the PROCESS entity and CPU entity displays shown above to determine the processor use of process $PATHF running in processor 2:

• 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 this formula:

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.

(PROCESS-Dispatches / CPU-Dispatches) * (Intr-Busy-Time - Send-Busy-Time)

31.20 + ((48.13 / 51.00) * (13.24 - 4.64)) = 39.32


Tuning Measuring Passthrough Traffic

Measuring Passthrough Traffic

Although passthrough traffic is reported in the SYSTEM entity (SENT-FWD and RCVD-FWD 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 line-handler 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.

Tuning ExamplesThe 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 the data shown was captured by Measure or SCF and then extracted manually and entered in spreadsheet programs.

Example 1: Changing Packet Size

This 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 19-6 on page 19-29 is an example of an SCF PATH STATS display.

Note. Measuring adds no burden to the measured entity; the counters maintained by the system are sampled by Measure without affecting the measured process.


Tuning Example 1: Changing Packet Size

The key statistics in Example 19-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 this formula:

This average message sizes are derived from the data shown:

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). This compares the packets per link required for 256-byte packets (frame size equal to 132 words) and 1024-byte packets:

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 regardless of what packet size is used

Example 19-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

average_message_size = (packets / links) * 192

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

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


Tuning Example 1: Changing Packet Size

because 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-per-link 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):

Increasing the packet size to 2048 bytes should increase efficiency slightly more because 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 256-byte size using this formula:

The bandwidth used for 1024-byte packets would be

1776 + (2 * 64) = 1904 = 15323 bits/message

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.

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

average_message_size + (number_of_packets * 64)


Tuning Example 2: Reducing Passthrough Traffic

Figure 19-6 shows a comparison of the bandwidths used for packets of 245, 1024, and 2048 bytes.

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 19-7 on page 19-32 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 19-7 on page 19-32 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

Figure 19-6. Packet Size/Bandwidth Comparison

Bits per

message

0

5000

10000

15000

20000

256 1024 2048

Packet Size

(Bytes)

VST029.vsd



through to other nodes. Passthrough traffic is shown in the SENT-FWD and RCVD-FWD 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.

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 cause a 40 percent reduction in unnecessary switched traffic. Additional benefits would include a reduction in the number of processors, communications devices, and communications links used on \JUICE and in the network.

Measuring Passthrough Traffic in an Entire Network

Example 19-8 on page 19-33 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.

Example 19-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

Note. The table in Example 19-8 on page 19-33 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 19-8 on page 19-33 is an illustration of one simple technique for deriving a thorough understanding of network performance from standard, readily available instrumentation.



Example 19-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.

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 because of 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.

Example 19-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%


20 Troubleshooting

To quickly and efficiently identify and resolve network problems, HP recommends that you use a standard network troubleshooting methodology.

• Understanding Your Network• Collecting Network Information• Identifying Network Problems on page 20-3• Resolving Specific Network Problems on page 20-11 • Reporting Network Problems on page 20-29• Resolving Common Network Problems on page 20-31

This section explains each of the elements of the troubleshooting methodology and shows you how to use it to resolve common Expand subsystem problems.

Understanding Your NetworkA 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 InformationThis 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.

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


Troubleshooting Measure

information about Expand subsystem components. Table 20-1 lists the TYPE identifiers you can use to show information about Expand subsystem components and related subsystems.

For more information on the Expand SCF commands, see Section 18, Managing the Network. About syntax information for SCF commands, see Section 14, Subsystem Control Facility (SCF) Commands.

Measure

Measure is an HP tool for monitoring the performance of Integrity NonStop NS-series servers. In an Expand network, Measure determines if the network is contributing to a performance problem. For more information on the Measure, see Section 19, 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 multi-node application environments. For more information on ASAP, see these manuals: ASAP Client Manual, ASAP Server Manual, ASAP Extension Manual, and ASAP Migration Guide for NSX and OMF Users.

Table 20-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)

61 X25AM processes

48 NonStop TCP/IP processes

45 QIO Monitor process (QIOMON)


Troubleshooting Identifying Network Problems

Identifying Network ProblemsThere 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 might 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 20-1. When you begin to identify a network problem, it is usually best to determine commonalities between all the errors reported beginning with the lowest layers.

This subsection contains examples that show how you can use these sources to identify a problem:

• User Complaints• SCF Commands

Figure 20-1. Network Problem Hierarchy

Note. For more information on interpreting performance information produced by tools such as Measure and ASAP, see the discussion of Measure in the Measure User’s Guide.

User

Application

End System

Route

Path

Lines

VST027.vsd


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. 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 20-2 shows how to verify system processes using the SCF LISTDEV command.

Table 20-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

A specific Expand line-handler process

Not applicable LISTDEV $device_name

All Expand line-handler processes

Not applicable LISTDEV TYPE 63

or

LISTDEV EXPAND


Troubleshooting SCF Commands

Example 20-1 shows an SCF LISTDEV display produced by a LISTDEV TYPE 63 command.

Expand Subsystem SCF Commands

Table 20-3 lists the Expand subsystem SCF commands that are most helpful when attempting to identify Expand subsystem problems.

Example 20-2 on page 20-6 and Example 20-3 on page 20-6 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 can be high during line setup; a large number of U-frames at any other time might indicate a fatal problem. (The U-Frames counter is highlighted in bold type.)

Example 20-1. SCF LISTDEV Display

LDev Name PPID BPID Type RSize Pri Program 26 $PBAL4 2,13 3,13 (63,1 ) 0 199 \TAHITI.$SYSTEM.T9057.LHOBJ 66 $A10 2,14 3,12 (63,6 ) 12 199 \TAHITI.$SYSTEM.SYS01.LHOBJ 68 $IPCOW 1,18 0,17 (63,0 ) 3 199 \TAHITI.$SYSTEM.SYS01.LHOBJ2 71 $EX25COW 2,11 3,15 (63,0 ) 12 199 \TAHITI.$SYSTEM.SYS01.LHOBJ 87 $B30S 2,10 3,16 (63,5 ) 12 199 \TAHITI.$SYSTEM.SYS01.LHOBJ 88 $B21 2,13 3,13 (63,6 ) 12 199 \TAHITI.$SYSTEM.T9057.LHOBJ 89 $B20 2,13 3,13 (63,6 ) 12 199 \TAHITI.$SYSTEM.T9057.LHOBJ 124 $ZEXP 1,23 0,23 (63,30) 132 180 \TAHITI.$SYSTEM.SYS01.OZEXP

Table 20-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.

Note. You should reset SCF statistics using the RESET command after starting a system or line or resolving a problem.



The SCF STATUS command displays in Example 20-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 20-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 DETAIL ----------------------------------- SABM DISC UA DM CMDR RR Sent 1 0 1 0 0 59229 Rcvd 1 0 1 0 0 50969 RNR REJ SREJ I-FRM I-FRM(P) Sent 0 0 0 40651 0 Rcvd 0 0 0 17053 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

Example 20-3. SCF STATUS Display

8-> status path $pbal4,detail EXPAND Detailed Status PATH $PBAL4 PPID........ ( 2, 13) BPID........... ( 3, 13) State....... STARTED Number of Lines.. 2 Trace Status OFF Superpath OFF Line LDEVs.. 88 89 9-> status line $88 EXPAND Status LINE Name State Status PPID BPID CIU-Path ConMgr-LDEV $B21 STARTED READY 2, 13 3, 13 A 30 10-> status line $89 EXPAND Status LINE Name State Status PPID BPID CIU-Path ConMgr-LDEV $B20 STARTED READY 2, 13 3, 13 A 30



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 20-4 shows an example of an SCF INFO PROCESS $NCP, LINESET display.

Table 20-4 lists and describes the file-system error numbers that are most commonly reported by the SCF INFO PROCESS $NCP, LINESET command.

Example 20-4. SCF INFO PROCESS $NCP, LINESET Display

-> INFO PROCESS $NCP, LINESET EXPAND Info PROCESS $NCP , LINESET LINESETS AT \NODEA (117) #LINESETS=7 TIME: FEB 24,2003 13:55:04 LINESET NEIGHBOR LDEV TF PID LINE LDEV STATUS FileErr# 1 S \NODEB (082) 122 1 ( 1, 334) 1 122 READY 2 S \NODEB (082) 123 1 ( 0, 333) 1 123 READY 3 S \NODEB (082) 121 1 ( 0, 332) 1 121 READY 4 \NODEB (082) 131 -- -- ----- 1 131 NOT READY (066) 5 \NODEB (082) 125 3 ( 2, 271) 1 125 READY 6 \NODEF (247) 132 -- -- ----- 1 132 NOT READY (066) 7 \NODEF (247) 175 -- -- ----- 1 212 NOT READY (066) 2 254 NOT READY (066) 3 256 NOT READY (066) 4 259 NOT READY (066)

Table 20-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 these 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 can 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 can be indicated and you should contact your HP representative.

Note. For more information on network-related file-system errors, see the Operator Messages Manual.



The SCF INFO PROCESS $NCP, NETMAP command is useful for displaying the current routing data. Example 20-5 on page 20-9 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.

140 This error indicates that the Expand line has been disconnected. The cause could be a problem with modem-to-system communications or with a phone line, a cable, or an X.25 connection.

For IP, ATM, 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, or $ZZSCL).

Examine the physical connections and modem settings to ensure that cables are plugged into the correct line interface unit (LIU).

Check the configuration of the ASSOCIATEDEV line modifier, if an IP, ATM, 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 can 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 can 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.

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 neighbor Expand line-handler process has not yet started, use the Expand subsystem SCF START command to start the line-handler process.

If the NEXTSYS or FRAMESIZE modifier is incorrect, correct it using the WAN subsystem SCF ALTER DEVICE command.

Table 20-4. Common File-System Errors (page 2 of 2)

Error Cause Recovery

Note. For more information on network-related file-system errors, see the Operator Messages Manual.



Example 20-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 TIME (DISTANCE) BY PATH INDEX 82 \NODEB 1(01)& 1(01)& 1(01)* inf(--) 3(01) inf(--) [ 6] inf(--) [ 7] 123 \NODEC 4(02) 4(02) 4(02)* inf(--) 6(02) inf(--) [ 6] inf(--) [ 7] 151 \NODEG inf(--) inf(--) inf(--) inf(--) inf(--) inf(--) [ 6] inf(--) [ 7] 160 \NODED inf(--) inf(--) inf(--) inf(--) inf(--) inf(--) [ 6] inf(--) [ 7] 247 \NODEF inf(--) inf(--) inf(--) inf(--) inf(--) inf(--) [ 6] inf(--) [ 7] 254 \NODEE 7(03)* 7(03) 7(03) inf(--) 9(03) inf(--) [ 6] inf(--) [ 7] --------------------------------------------------------------- LINESETS AT \NODEA (117) #LINESETS=7 LINESET NEIGHBOR LDEV TF PID LINE LDEV STATUS FileErr# 1 S \NODEB (082) 122 1 ( 1, 334) 1 122 READY 2 S \NODEB (082) 123 1 ( 0, 333) 1 123 READY 3 S \NODEB (082) 121 1 ( 0, 332) 1 121 READY 4 \NODEB (082) 131 -- -- ----- 1 131 NOT READY (066) 5 \NODEB (082) 125 3 ( 2, 271) 1 125 READY 6 \NODEF (247) 132 -- -- ----- 1 132 NOT READY (066) 7 \NODEF (247) 175 -- -- ----- 1 212 NOT READY (066) 2 254 NOT READY (066) 3 256 NOT READY (066) 4 259 NOT READY (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 20-6 shows a sample display of the SCF PROBE PROCESS, $NCP command.

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 20-5 summarizes how to use HP utilities to identify network problems.

Example 20-6. SCF PROBE PROCESS, $NCP Display

6-> PROBE PROCESS $NCP, AT \NODEA, TO \NODEC EXPAND Probe PROCESS $NCP NETPROBES AT \NODEA (016) TIME: 17 FEB 1997, 10:19:13 113 \NODEC - \NODEW - \NODER - \NODET - \NODEM - * (0086)

Table 20-5. Network Problem Check List

Utility Information Produced

EMS Events collected by the Event Management Service (EMS) can be viewed using the OSM event viewer.

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.


Troubleshooting Resolving Specific Network Problems

Resolving Specific Network ProblemsThis subsection provides checklists for solving these 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 20-6 lists SCF commands that are useful for diagnosing problems with $NCP.

Table 20-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

or

INFO PROCESS $NCP

Displays configuration information for $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 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 in addition to 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.


Troubleshooting Expand Line-Handler Process Problems

Expand Line-Handler Process Problems

Table 20-7 lists procedures to help you resolve Layer 4 and Layer 2 Expand line-handler process problems.

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 multi-CPU 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.

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 17-13.

Table 20-7. Expand Line-Handler Process Problem-Resolution Procedures (page 1 of 2)

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-to-End 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 these problems:

• 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

Table 20-6. Identifying $NCP Problems With SCF Commands

Command Use


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 20-8 to solve problems related to SWAN concentrators.

Expand Layer 2 protocol

You can use the SCF STATS LINE command to examine Layer 2 statistics. Figure 20-1 on page 20-3 (earlier in this section) is an example of an SCF STATS LINE command.

Table 20-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 this 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 this 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 these 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.

Table 20-7. Expand Line-Handler Process Problem-Resolution Procedures (page 2 of 2)

Problem Procedure


Troubleshooting SWAN Concentrator Problems

Common SWAN Concentrator Problems

This is a list of common SWAN concentrator problems:

• The SWAN concentrator’s Ethernet ports are connected to the wrong Ethernet segments.

• One or both of the SWAN concentrator’s Ethernet ports are connected to a nonoperational Ethernet segment.

• Both of the SWAN concentrator’s Ethernet ports are connected to the same Ethernet segment, and the alternate NonStop TCP/IP process (ALTTCPIP attribute) is configured as a NonStop TCP/IP process on the same segment. The SNMPCODE file will not download in this configuration. If you must connect both

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 these SCF commands:

STATUS PATH $ZZWAN.#conc-name.1.a STATUS PATH $ZZWAN.#conc-name.1.b STATUS PATH $ZZWAN.#conc-name.2.a STATUS PATH $ZZWAN.#conc-name.2.b STATUS PATH $ZZWAN.#conc-name.3.a STATUS PATH $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).

Check the SWAN kernel code version.

To display the version of the SWAN kernel code installed on a SWAN concentrator, use this 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 subsystem SCF commands. An EMS message similar to this will be displayed on your terminal:

TANDEM.WANMGR.H01 001502 WANBoot: BOOTP received for SWANB TRACKID VOZN6H, CLIP 1, IP Address 192.168.111.201, Path A VPROC: T7954G01^18SEP2002^AAL^R002 WARNING: Firmware version mismatch. Firmup to resolve.

The SWAN kernel version is shown in line beginning with VPROC.

Table 20-8. SWAN Concentrator Problem-Resolution Check List (page 2 of 2)

Task Procedure


Troubleshooting WAN Subsystem Problems

Ethernet ports to the same segment, either omit ALTTCPIP or set it to a NonStop TCP/IP process that does not exist. Both solutions will cause this EMS message: “Connected to Wrong ETHERNET PORT.”

• The SWAN concentrator’s Ethernet ports are reversed. If the ports are reversed, you will receive this EMS message: “Connected to Wrong ETHERNET PORT.”

• There is a firmware failure in a communications line interface processor (CLIP) before the FIRMUP procedure. Power cycle the SWAN concentrator if the kernel is nonresponsive.

For more information on configuring a SWAN concentrator, see the WAN Subsystem Configuration and Management Manual.

WAN Subsystem Problems

Expand line-handler processes and $NCP are WAN subsystem devices; they rely on various WAN subsystem components to operate correctly. This subsection provides WAN subsystem troubleshooting guidelines and identifies common WAN subsystem configuration problems.


Use the check list provided in Table 20-9 to solve problems related to the WAN subsystem.

Table 20-9. WAN Subsystem Problem-Resolution Check List (page 1 of 2)

Task Procedure

Check the state of the WAN subsystem manager process ($ZZWAN).

To determine if $ZZWAN is running, use this SCF command:

STATUS PROCESS $ZZKRN.#ZZWAN

If $ZZWAN is not running, it must be started. See the WAN Subsystem Configuration and Management Manual.

Check the configuration of the WAN subsystem manager process ($ZZWAN).

To display configuration information for $ZZWAN, use this SCF command:

INFO PROCESS $ZZKRN.#ZZWAN

If $ZZWAN is not configured correctly, it must be reconfigured. See the WAN Subsystem Configuration and Management Manual.



Check the state of the default Subsystem Control Point (SCP) manager process ($ZNET).

To determine if $ZNET is running, use this command at the TACL prompt:

STATUS $ZNET

Typically, there should be a permanent SCP process called $ZNET on each Integrity NonStop server that SCF uses by default. If $ZNET is not running, SCF starts its own SCP process (which is removed when SCF is stopped).

Check the state of each NonStop TCP/IP process used by the WAN subsystem.

To determine if the NonStop TCP/IP processes are running, use this SCF command:

STATUS PROCESS $process_name

To display the dynamic state of the TCP/IP SUBNETs, use this SCF command:

STATUS SUBNET $process_name.*

If the NonStop TCP/IP processes are not running, they must be started. See the WAN Subsystem Configuration and Management Manual.

Check the state of the Trivial File Transfer Protocol (TFTP) server process assigned to each NonStop TCP/IP process.

To determine if the TFTP server processes are running, use this SCF command:

STATUS PROCESS $ZZWAN.#ZFnnn

If the TFTP server processes are not running, they must be started. See the WAN Subsystem Configuration and Management Manual.

Check the state of the WANBoot process assigned to each NonStop TCP/IP process used by the WAN subsystem.

To determine if each WANBoot process is running, use this SCF command:

STATUS PROCESS $ZZWAN.#ZWnnn

If the WANBoot processes are not running, they must be started. See the WAN Subsystem Configuration and Management Manual.

Check the state of the concentrator manager (ConMgr) process in each processor where a WAN input-output process (IOP) will run.

To determine if the ConMgr processes are running, use this SCF command:

STATUS PROCESS $ZZWAN.#n

ConMgr processes are configured with the number of the processor they are to run in. For example, $ZZWAN.#0 runs in processor 0.

If the ConMgr processes are not running, they must be started. See the WAN Subsystem Configuration and Management Manual.

Table 20-9. WAN Subsystem Problem-Resolution Check List (page 2 of 2)

Task Procedure



Common WAN Subsystem Problems

This is a list of common WAN subsystem problems:

• The SNMPCODE, KERNELCODE, or PROGRAM file is not in the correct subvolume or is not secured for “N” read access (the leftmost character in the file security string). SNMPCODE and KERNELCODE are download files for the SWAN concentrator; PROGRAM is a microcode file where the data link control (DLC) task is located. These files must be in a subvolume authorized for access by the TFTP servers. The correct subvolume is $SYSTEM.CSSnn. For example, if the current running SYSnn is SYS00, then the correct subvolume is $SYSTEM.CSS00.

• The NonStop TCP/IP processes used by the WAN subsystem are not configured correctly. For example:

• You must configure a SUBNET object (SCF ADD SUBNET command) for each connection to a network. The SUBNET object is the point of connection between the NonStop TCP/IP process and the ServerNet LAN Systems Access (SLSA) subsystem.

• Each SUBNET must be associated with the correct Internet Protocol (IP) address (IPADDRESS attribute) and subnet mask (SUBNETMASK attribute).

• Each time you add a SUBNET, a route is automatically created. A route (ROUTE object) is the path a data packet travels to reach its destination. You must issue an SCF START ROUTE command to create implicit connections to and from a route.

For complete information about TCP/IP process configuration, see the TCP/IPv6 Configuration and Management Manual.

For more information on configuring the WAN subsystem, see the WAN Subsystem Configuration and Management Manual


Troubleshooting Expand-Over-X.25 Problems

Expand-Over-X.25 Problems

Table 20-10 provides general suggestions to help you solve problems with Expand-over-X.25 lines.

Table 20-10. Expand-Over-X.25 Problem-Resolution Procedures

Task Procedure

Check the X25AM process that controls the X.25 line to make sure that the line is operational and that the appropriate subdevice(s) are started.

To verify that a subdevice is correct, use the X25AM subsystem SCF INFO SU command. Look for these information when using the INFO SU command:

• The PROTOCOL parameter must be NAM.

• The DEVTYPE must be (63,0).

• The DESTADDR parameter must appear if this node is issuing a call request.

• The PORT parameter must be set to a value that is unique to the subdevice (other subdevices on the line should not be assigned to the same port).

If the appropriate subdevice(s) have not been started, start them using the X25AM subsystem SCF START SU command.

If the appropriate subdevice(s) cannot be found, add them to the node using the X25AM subsystem SCF ADD SU command.

Check the Expand-over-X.25 line-handler process to make sure the ASSOCIATEDEV modifier specifies the correct X25AM process name.

To display the ASSOCIATEDEV modifier value, use this Expand subsystem SCF command:

INFO LINE $device_name

Check the Expand-over-X.25 line-handler process to make sure the NEXTSYS modifier is set to the correct node (system) number.

To display the NEXTSYS modifier value, use this Expand subsystem SCF command:

INFO PATH $device_name

Determine if other X.25 line functions are operational.

Try to use the X.25 line for another purpose, such as connecting to a remote PAD. File-system error 140 usually indicates an X25AM error; file-system error 124 usually indicates an Expand subsystem error.

Check the SWAN concentrator. The Expand subsystem SCF STATS LINE command can help you determine if the problem is caused by the SWAN concentrator. See SWAN Concentrator Problems on page 20-13.


Troubleshooting Expand-Over-IP Problems

Expand-Over-IP Problems

You can diagnose most Expand-over-IP line-handler process problems using information provided by the Expand subsystem SCF STATUS LINE command with the DETAIL option. This command provides error information in the Detailed State and Detailed Info fields. Example 20-7 shows an SCF STATUS LINE, DETAIL command display. (The Detailed State and Detailed Info fields are shown in boldface type.)

Detailed State Field For Expand-Over-IP Lines

Table 20-11 describes the detailed states displayed in the Detailed State field for Expand-over-IP line-handler processes.

Example 20-7. SCF STATUS LINE, DETAIL Command

-> STATUS LINE $SC151, DETAIL EXPAND Detailed Status LINE $SC151 PPID............... ( 2, 282) BPID................. ( 3, 282) State.............. STARTED Path LDEV............ 109 Trace Status....... OFF Effective line priority 1 Detailed State..... CONNECTED Status READY Detailed Info... None Trace File Name.... \NODEA.$DATA00.STATUS.TRC

Table 20-11. Detailed States (Expand-Over-IP) (page 1 of 3)

Detailed State Cause/Effect Recovery

BINDING The Expand-over-IP line-handler process is binding to the local NonStop TCP/IP process.

This state is normal while the line is coming up. If the line remains in this state, an internal error might have occurred.

If this state persists, contact your HP support representative.

CONNECTED A connection has been established. This state is normal. No recovery is required.

CONNECTING The Expand-over-IP line-handler process has connected to the local NonStop TCP/IP process is and is now attempting to connect to the remote Expand-over-IP line-handler process.

This state is normal while the connection is being established. If the line remains in this state, the remote Expand-over-IP line-handler process cannot be operational or there can be a network problem.

Use the SCF STATS LINE and SCF INFO LINE commands to further diagnose the problem. These commands are described in Resolving Expand-Over-IP Connection Problems on page 20-21.



DOWN The Layer 2 functions of the Expand-over-IP line-handler process are down. The operator might have brought the line down, the line was never started, or a problem occurred that prevented the line from starting.

If an error has occurred, additional information will appear in the Detailed Info field. The Detailed Info field is described in Detailed Info Field for Expand-Over-IP Lines on page 20-23.

DOWN SOCKET This is an internal state that should not persist.

Try to restart the line. If this state persists, contact your HP representative.

DOWN WAIT This is an internal state that should not persist.


PASSIVE If the Expand-over-IP line-handler process is configured to issue passive connect requests, this state indicates that the line-handler process is waiting for the remote Expand-over-IP line-handler process to initiate a connection.

If the Expand-over-IP line-handler process is configured to issue active connect requests, this state indicates that the reconnect limit has been reached and that the line-handler process has been configured to subsequently issue passive connect requests.

This state is normal. No recovery is required.

QUERY A connection has been established with the remote Expand-over-IP line-handler process, but no data has been received within the inactivity interval. The Expand-over-IP line-handler process is sending Probe messages to the remote Expand-over-IP line-handler process to verify that it is operational.

If the line remains in this state, the remote (destination) Expand-over-IP line-handler process is down or there is a network problem.

SOCKET_REUSE This is an internal state that should not persist.


SOCKET SETUP This is an internal state that should not persist.






Resolving Expand-Over-IP Connection Problems

If the SCF STATUS LINE, DETAIL command displays CONNECTING in the Detailed State field, use the SCF STATS LINE command to obtain more information about the problem. Example 20-8 shows an SCF STATS LINE command.

If the line is configured to issue active connect requests, determine if Connect Command frames (Conn Cmd column) are being sent (Send row). If the line is configured in passive connect mode, determine if Connect Command frames (Conn Cmd column) are being received (Rcvd row). If no Connect Command frames are being sent or received, the destination line-handler process can not be operational or there can be a network problem.

If the Invalid Frames Rcvd counter is greater than 0, frames are being corrupted; contact your HP support representative.

If the Invalid IP Addr Rcvd counter is greater than 0, the Internet Protocol (IP) address configured for either the local or destination Expand-over-IP line-handler process can be invalid. Use the SCF INFO LINE command with the DETAIL option to display the configured IP addresses and associated NonStop TCP/IP process. Example 20-9 shows an SCF INFO LINE command display. (The relevant fields are shown in boldface type.)

SOCKET_SPACE This is an internal state that should not persist.


WAIT The Expand-over-IP line-handler process is waiting for another process or subsystem.

The line remains started but is not ready for data transfer.

For more specific error information, see the Detailed Info field. Recovering from these types of problems is described further in Resolving Expand-Over-IP Wait Problems on page 20-22.

Example 20-8. SCF STATS LINE Command (Expand-Over-IP)

- > 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 Conn Cmd Conn Resp Data Query Cmd Query Resp Scnd 0 0 0 0 0 Rcvd 0 0 0 0 0 Invalid Frames Rcvd 0 Invalid IP Addr Rcvd 0 Frames Dropped 0 Tx Window Available 0 Mem Low 0 Line Quality 100





Resolving Expand-Over-IP Wait Problems

If the SCF STATUS LINE command with the DETAIL option displays WAIT in the Detailed State field, check the Detailed Info field for more detailed error information. Table 20-12 describes the messages that might be displayed in the Detailed Info field.

Example 20-9. SCF INFO LINE, DETAIL Command (Expand-Over-IP)

-> INFO LINE $IPTAH0, DETAIL

EXPAND Detailed Info LINE $IPTAH0 (LDEV 175)

L2Protocol Net^Ip TimeFactor...... 3 *SpeedK........ NOT_SET Framesize....... 132 -Rsize........... 3 -Speed........*LinePriority.... 1 StartUp......... OFF *Delay......... 0:00:00.10*DownIfBadQuality OFF *QualityThreshold 96 *QualityTimer.. 0:01:00.00*Txwindow........ 7 *Maxreconnects... 0 *AfterMaxRetries PASSIVE*Timerreconnect 0:00:30.00 *Retryprobe...... 19 *Timerprobe.... 0:00:01.00*Associatedev.... $ZTC02 *LineTf.......... 0 *Timerinactivity 0:00:00.00*IPVer IPV4*DestIpAddr 16.107.189.66 *DestIpPort...... 5744*SrcIpAddr 16.107.188.54 *SrcIpPort....... 5744*V6DestIpAddr ::*V6SrcIpAddr ::

Table 20-12. Messages Displayed in the Detailed Info Field (Expand-Over-IP)

Message Description

Shared memory system unavailable The QIO subsystem is not available. Check the state of the QIO subsystem. The line will become ready when the QIO subsystem becomes available.

Ownership error The Expand-over-IP line-handler process is unable to switch processors. An ownership error occurs when the NonStop TCP/IP process associated with the Expand-over-IP line-handler process indicates that it is no longer the primary process, but the line-handler process is unable to switch processors because other lines in the multi-line path are active. (An Expand-over-IP line-handler process and the NonStop TCP/IP process with which it is associated must always reside in the same processor.) The Expand-over-IP line-handler process will not be able to switch processors until all other lines in the path are inactive (that is, they do not have socket connections).

Associate TCP process unavailable The NonStop TCP/IP process associated with the Expand-over-IP line-handler process is not available. Check the state of the NonStop TCP/IP process. The line will become ready when the associated NonStop TCP/IP process becomes available.


Troubleshooting Expand-Over-ATM Problems

Detailed Info Field for Expand-Over-IP Lines

The Detailed Info field displays the last error message returned to the Expand-over-IP line-handler process. 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 20-13 describes the messages that can be returned to the Detailed Info field.


Expand-Over-ATM Problems

You can diagnose most Expand-over-ATM line-handler process problems using information provided by the Expand subsystem SCF STATUS LINE command with the DETAIL option. This command provides error information in the Detailed State and Detailed Info fields. Example 20-10 shows an SCF STATUS LINE, DETAIL command display. (The Detailed State and Detailed Info fields are shown in boldface type.)

Table 20-13. Messages and Corresponding Event Numbers


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

Example 20-10. SCF STATUS LINE, DETAIL Command

- > status line $atmtst, detail EXPAND Detailed Status LINE $ATMTST PPID............ (2, 72) BPID............ (3, 74) State........... STARTED Path LDEV....... 165 Trace Status.... OFF Detailed State.. CONNECTING Detailed Info... ATM subsystem error 123, Info %H04C4B47B, Loc %456



Detailed State Field for Expand-Over-ATM Lines

Table 20-14 describes the detailed states displayed in the Detailed State field for Expand-over-ATM line-handler processes.

Table 20-14. Detailed States (Expand-Over-ATM) (page 1 of 2)


ACCEPT A switched virtual circuit (SVC) connection has been accepted from the remote system.


BINDING The Expand-over-ATM line-handler process is binding to the configured permanent virtual circuit (PVC) name.

This state is normal while the line is coming up. If the line remains in this state, an internal error might have occurred.


CALLING The Expand-over-ATM line-handler process is attempting to establish a switched virtual circuit (SVC) connection to the remote system.


CONNECTED A connection has been established This state is normal. No recovery is required.

CONNECTING The Expand-over-ATM line-handler process is attempting to connect to the remote (destination) Expand-over-ATM line-handler process.

This state is normal while the connection is being established. If the line remains in this state, the remote Expand-over-ATM line-handler process can not be operational or there can be a network problem.

Use the SCF STATS LINE and SCF INFO LINE commands to further diagnose the problem. These commands are described in Resolving Expand-Over-ATM Connection Problems on page 20-26.

DOWN The Layer 2 functions of the Expand-over-ATM line-handler process are down. The operator might have brought the line down, the line was never started, or a problem occurred that prevented the line from starting.

If an error has occurred, additional information will appear in the Detailed Info field. The Detailed Info field is described in Detailed Info Field for Expand-Over-ATM Lines on page 20-27.

DOWN WAIT This is an internal state that should not persist.




LISTEN The Expand-over-ATM line-handler process is waiting for switched virtual circuit (SVC) connection establishment from the remote system.


PASSIVE If the Expand-over-ATM line-handler process is configured to issue passive connect requests, this state indicates that the line-handler process is waiting for the remote Expand-over-ATM line-handler process to initiate a connection.

If the Expand-over-ATM line-handler process is configured to issue active connect requests, this state indicates that the reconnect limit has been reached and that the line-handler process has been configured to subsequently issue passive connect requests.


QUERY A connection has been established with the remote Expand-over-ATM line-handler process, but no data has been received within the inactivity interval. The Expand-over-ATM line-handler process is sending Probe messages to the remote Expand-over-ATM line-handler process to verify that it is operational.

If the line remains in this state, the remote (destination) Expand-over-ATM line-handler process is down or there is a network problem.

SETOPT_CALLING This is an internal state that should not persist.


SETOPT_LISTEN This is an internal state that should not persist.


WAIT The Expand-over-ATM line-handler process is waiting for another process or subsystem.

The line remains started but is not ready for data transfer.

For more specific error information, see the Detailed Info field. Recovering from these types of problems is described further in Resolving Expand-Over-ATM Wait Problems on page 20-27.

Table 20-14. Detailed States (Expand-Over-ATM) (page 2 of 2)




Resolving Expand-Over-ATM Connection Problems

If the SCF STATUS LINE, DETAIL command displays CONNECTING in the Detailed State field, use the SCF STATS LINE command to obtain more information about the problem. Example 20-11 shows an SCF STATS LINE command.

If the line is configured to issue active connect requests, determine if Connect Command frames (Conn Cmd column) are being sent (Sent row). If the line is configured in passive connect mode, determine if Connect Command frames (Conn Cmd column) are being received (Rcvd row). If no Connect Command frames are being sent or received, the destination line-handler process can not be operational or there can be a network problem.

If the Invalid Frames Rcvd counter is greater than 0, frames are being corrupted; contact your HP support representative.

If the Invalid ATM Addr Rcvd counter is greater than 0, the ATM address configured for either the local or destination Expand-over-ATM line-handler process might be invalid. Use the SCF INFO LINE command with the DETAIL option to display the ATM address configured for the destination Expand-over-ATM line-handler process.

Example 20-12 shows an SCF INFO LINE command display for an Expand-over-ATM line-handler process that uses a switched virtual circuit (SVC). (The relevant fields are shown in boldface type.)

Example 20-11. SCF STATS LINE Command (Expand-Over-ATM)

-> 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 Conn Cmd Conn Resp Data Query Cmd Query Resp Sent 0 0 0 0 0 Rcvd 0 0 0 0 0 Invalid Frames Rcvd 0 Invalid ATM Addr Rcvd 0 Frames Dropped 0 Tx Window Available 0 Mem Low 0 Line Quality 100

Example 20-12. SCF INFO LINE, DETAIL Command (SVC Connection)

- > INFO LINE $ATMH, DETAIL EXPAND Detailed Info LINE $ATMH *Associatedev. $AM3 *Associatesubdev #IP Rsize........ 3 *Speed.......... 74666 Delay.......... 0:00:00.10 Framesize.... 132 Txwindow....... 7 *Timerinactivity 0:00:00.00 *Maxreconnects 0 *Timerreconnect 0:00:30.00 *AfterMaxRetries PASSIVE *Timerprobe...0:00:30.00 *Retryprobe..... 3 StartUp........ OFF L2Protocol... Net^Atm ConnEp.........%H30100958 ListenEp....... %H30100654 *CallType..... SVC VPI............ 0 VCI............ 0 *AtmSel....... %H80 *DestAtmAddr.. (ISONSAP:%H47009181000100006170597C0140000C80001000)



Resolving Expand-Over-ATM Wait Problems

If the SCF STATUS LINE command with the DETAIL option displays WAIT in the Detailed State field, check the Detailed Info field for more detailed error information. Table 20-15 describes the messages that might be displayed in the Detailed Info field.

Detailed Info Field for Expand-Over-ATM Lines

The Detailed Info field displays the last error message returned to the Expand-over-ATM line-handler process. 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 14-7 on page 14-109 describes the messages that can be returned to the Detailed Info field.


Table 20-15. Messages Displayed in the Detailed Info Field (Expand-Over-ATM)

Message Description

Shared memory system unavailable The QIO subsystem is not available. Check the state of the QIO subsystem. The line will become ready when the QIO subsystem becomes available.

ATM subsystem unavailable, error nnn

The ATM line associated with the Expand-over-ATM line-handler process is not available. Check the state of the ATM line. The Expand-over-ATM line will become ready when the associated ATM line becomes available. ATM error codes (nnn) are described in the ATM Configuration and Management Manual.

PVC unavailable, error nnn The ATM permanent virtual circuit (PVC) used by the Expand-over-ATM line-handler process is not available. Make sure the PVC is configured properly. The Expand-over-ATM line will become ready when the associated ATM line becomes available. ATM error codes (nnn) are described in the ATM Configuration and Management Manual.

SVC unavailable, error nnn The ATM switched virtual circuit (SVC) used by the Expand-over-ATM line-handler process is not available. Make sure the SVC is configured properly and that network connectivity is functional. The Expand-over-ATM line will become ready when the associated ATM line becomes available. ATM error codes (nnn) are described in the ATM Configuration and Management Manual.


Troubleshooting Multi-CPU Path Problems

Multi-CPU Path Problems

This subsection provides multi-CPU path troubleshooting guidelines and identifies common multi-CPU path problems.


Table 20-16 provides general suggestions to help you solve problems with multi-CPU paths.

Table 20-16. Multi-CPU Path Problem Resolution Procedures

Task Procedure

Check that the multi-CPU path is enabled.

Use this SCF command to see if the paths you expect to be part of the multi-CPU path are actually configured:


If some of the paths do not display an “S” next to the LINESET number, then either the local or remote Expand line-handler process does not have the SUPERPATH modifier enabled. Use this SCF command on both the local and remote Expand line-handler processes to determine which line-handler process configuration is in error:

INFO PATH $device_name, DETAIL

Determine if the traffic is balanced over all paths in the multi-CPU path

Use this SCF command to find the base time factor (TF) effective time factor (ETF) for all paths that are part of the multi-CPU path:

INFO PATH $NCP, SUPERPATH

The load factors (LFs) of all the paths in the multi-CPU path should be roughly the same. (The LF is the ETF divided by the base TF.) If they are not, rebalance the paths using this SCF command:

ACTIVATE PROCESS $NCP, REBALANCE \system_name

where system_name identifies the multi-CPU path to be rebalanced.

Caution. 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 we recommend limiting rebalances to off-peak hours unless an imbalance is clearly causing immediate problems.


Troubleshooting Reporting Network Problems

Common Multi-CPU Path Problems

This is a list of common multi-CPU path problems:

• You received this EMS message during load balancing: “Network Requests Aborted.” This message does not indicate that a problem exists; it is generated when an Expand line-handler process pair is changed and messages that were in transit are aborted. These messages are retried by the file system.

• You tried to rebalance the multi-CPU path several times, but the load factors (LFs) indicate that the paths are still not balanced. First, wait a few minutes; it might take a while for the ETFs to stabilize at their new values. If the ETFs are still not balanced after a few minutes, then it is likely that most of the traffic is between just one or a few pairs of endpoints, making it impossible to spread the load over all the paths in the multi-CPU path. If this is not the case and the problem is severe, then stop and restart one path to force traffic to be redistributed.

Reporting Network ProblemsIf you need to bring a problem to the attention of your HP representative, HP recommends that you have these information available:

• A description of the problem (either verbal or written).

• Any related error messages.

• Action taken to resolve the problem.

• Results of traces taken up to the point of failure. (How and when to take a trace is explained in Tracing.)

• Memory dumps when the system freezes. (Online dumps are of minimal use.)

• Other supporting information, such as:

° System environmental information

° Results of running utility status-type commands

° Results of diagnostics

Tracing

Tracing is initiated using the Expand subsystem SCF TRACE command. Tracing allows HP personnel to see the history of a data communications link, including significant points in the internal processing of the traced entity. For tracing to be an effective, fault-finding tool, 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.


Troubleshooting Tracing

• 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 4-megabyte file is generally sufficient for all but the longest or most work-intensive traces.

• Gather a $NCP trace even if you don’t think the problem involves $NCP. It is preferable to have too much rather than too little information.

Tracing $NCP

To start a trace of $NCP, use this command:

TRACE PROCESS $NCP, TO $file_name, SELECT ALL, WRAP, RECSIZE 500

To stop the trace, use this command:

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, use this command:

TRACE PATH $device_name, TO $file_name, SELECT ALL, WRAP


TRACE PATH $device_name, STOP

$device_name specifies the device name of the path logical device or single-line Expand line-handler process. $file_name specifies the name of the file to which the trace records will be written.

Tracing a Line in a Multi-Line Path

To start a trace of a line that is part of a multi-line path, use this command:

TRACE LINE $device_name, TO $file_name, SELECT ALL, WRAP


TRACE LINE $device_name, STOP

$device_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.

Note. A TRACE PATH command will also trace all lines in a multi-line path, unless a TRACE LINE command has already been issued for one or more lines in the path.

Note. Trace files can be displayed using the commands available in the PTrace program. For more information on the PTrace, see the PTrace Reference Manual. For more information on the SCF TRACE command, see Section 15, Tracing.


Troubleshooting Resolving Common Network Problems

Resolving Common Network ProblemsThis subsection shows you, through examples, how to solve several common network problems. These problems include:

• Slow Response Time• Network Congestion• Node Not Available

• Path Down• Line(s) Down

• Duplicate Node

Slow Response Time

Slow response time is indicated when network response is worse than expected relative to normal day-to-day performance.

These five steps should be taken when attempting to resolve problems of slow response time between nodes in the network.

Step 1: PROBE between nodes

To send a probe between nodes, use this Expand subsystem SCF command:

PROBE PROCESS $NCP, AT \system1, TO \system2

If the probe time is slower than expected, probe shorter sections of the path to locate the bottleneck. Example 20-13 shows a probe sent between \TARHEEL and \CASG.

You can use the list of node names provided by the PROBE display to probe a shorter route each time until the node responsible for the bottleneck is found.

Example 20-13. SCF PROBE Display

6-> probe process $ncp, at \tarheel, to \casg EXPAND Probe PROCESS $NCP NETPROBES AT \TARHEEL (016) TIME: 17 FEB 1997, 10:19:13 113 \CASG - \NCWIND - \NCCORP - \NCTERM - \MEMPHIS - * (0086)

Note. SCF probes are small packets with a higher priority than normal node messages. Only one probe can be initiated on a particular node at one time.


Troubleshooting Slow Response Time

Step 2: Display routing data

After you have isolated the path to the nodes causing the bottleneck, use this Expand subsystem SCF command to display the routing data of the network control process ($NCP) at one end of the slow path:

INFO PROCESS $NCP, NETMAP, AT \system-name

Example 20-5 on page 20-9 shows an example of an INFO PROCESS $NCP, NETMAP display.

Step 3: Display path information

After you have identified the best-path route, use this Expand subsystem SCF command to display information about the path:


Example 20-4 on page 20-7 is an example of an INFO PROCESS $NCP, LINESET command.

Step 4: Analyze Layer 2 statistics

You can use the logical device (LDEV) number in this SCF command to analyze the Layer 2 statistics and further isolate the problem:

STATS LINE $ldev_number

Example 20-2 on page 20-6, is an example of an SCF STATS LINE display.

If a line is causing a problem, you will see these Layer 2 statistics:

• Congestion and delays because of heavy usage (the ratio of I-Frames to RR-Frames). I-Frames (or information frames) contain Expand packets. RR-Frames (or receive ready frames) are used to acknowledge information frames or simply report the link’s ready status to the other node.

• Slow links because of a large number of errors (high number of BCC or FCS errors)

When a line is under a heavy load, a STATS LINE command will typically display an unusually large number of I-Frames and virtually no S-Frames (supervisory frames, of which RR-Frames are the most common). RR-Frames will not be displayed because an I-Frame is always available to carry the acknowledgment.

Step 5: Analyze Layer 4 statistics

If the Layer 2 information gathered in Step 4 indicates nothing out of the ordinary, check the path for Layer 4 problems. Methods for gathering Layer 4 statistics are explained in Table 20-7 on page 20-12.


Troubleshooting Network Congestion

Network Congestion

Slow response time indicate network congestion, which can be caused by these conditions:

• Too much traffic for the current network capacity.

• A node or nodes that are fully operational but unable to process the traffic, causing bottlenecks.

• Peak loading of the network, causing temporary congestion.

• A downed path causing rerouting of traffic to other nodes (see Path Down on page 20-34).

• A link or links down in a path, reducing the net capacity of the path (see Line(s) Down on page 20-35).

• High number of errors on a path, reducing its net efficiency (see Slow Response Time on page 20-31).

The first three items usually point to assumptions that were made about network capacity, network growth, or processing power, any one or more of which were lower than required to efficiently operate the network.

For more information on network design and planning, see Section 3, Planning a Network Design and Section 4, Planning for ServerNet Clusters.

Node Not Available

These symptoms can indicate that a node is unreachable:

• File-system error 66, 140, 218, or 248 is returned to the application or by the Expand subsystem SCF INFO PROCESS $NCP, LINESET command.

• When the Expand subsystem SCF PROBE PROCESS $NCP command is used to probe the node, it fails (file-system error 250).

Your first attempt at resolving the problem should be at the End-to-End (Layer 4) level of the Expand line-handler process. To check the Layer 4 connection, use this Expand subsystem SCF command to examine the failing node’s routing table:

INFO PROCESS $NCP, NETMAP, TO node-name

An example of an INFO PROCESS, $NCP NETMAP display is shown in Example 20-5 on page 20-9.

If the best-path route is indicated in the INFO PROCESS $NCP, NETMAP display with a plus sign (+), then the $NCP-to-$NCP connection request is outstanding and the connection has not yet been established between the selected node and the displayed node through this path.

Note. If the best-path route is indicated with an asterisk (*), the selected node is connected to the displayed node through the path (the best-path route).


Troubleshooting Node Not Available

If the path displays a plus sign (+), you should first attempt to resolve the outstanding request problem by issuing an Expand subsystem SCF ABORT PATH command to the identified path and then issuing an Expand subsystem SCF START PATH command to start it again.

If the path constantly displays the plus sign (+), this indicates that the connection cannot be established. One solution to this problem is to abort all the Expand paths leaving the failing node, switch to the backup $NCP to reinitialize the node by using the Expand subsystem SCF PRIMARY PROCESS command, and then restart all paths:

ABORT PATH $device_name1, $device_name2, ... PRIMARY PROCESS $NCP, CPU cpu-number START PATH $device_name1, $device_name2, ...

If the Expand subsystem SCF INFO PROCESS $NCP, NETMAP command does not show a best-path route, use the Expand subsystem SCF PROBE PROCESS $NCP command to probe shorter sections of the route to determine how far the probe reaches. You must have a copy of the network map to perform this step.

A node can also be unreachable if it has been loaded with the same node number but a different node name. In this case, the Expand subsystem SCF INFO PROCESS $NCP, LINESET command would show the lineset as READY, but the node name would not be displayed. The $NCP on the local node will not connect with the $NCP on the remote node until the obsolete node name is removed from the network routing table (NRT). Use the Expand subsystem SCF DELETE ENTRY $NCP command to remove the obsolete node name from the NRT.

Path Down

A node can be unavailable because of a downed (nonoperational) path. You can locate a downed path using the Expand subsystem SCF commands listed in Table 20-17.

When you find a downed path, check for these conditions:

• Is this path/line always down?• Are there any configuration errors (especially event message 92 or 93)?• Is the cabling operational?

To gather more information about the path, ask the operator at the other end of the path to use the Expand subsystem SCF INFO command to check the current line attributes. When analyzing SCF INFO command information, verify these line attributes:

Table 20-17. SCF Commands to Locate a “Downed” Path

Expand Subsystem SCF Command Display Field What It Shows

INFO PROCESS $NCP, LINESET Status NOT READY (error_number)

STATUS PATH $device_name State STOPPED

STATUS LINE $device_name Status ERR (error_number)


Troubleshooting Node Not Available

• NEXTSYS modifier value. A large number of Level-2 DISC (disconnect) supervisory frames usually indicates an incorrect NEXTSYS number.

• Interface selection (RS-232 or RS-422). The controller defines its pinouts by the proper setting of the interface.

• ASSOCIATEDEV modifier and the system load command files for Expand-over-X.25, Expand-over-SNA, and Expand-over-IP, and Expand-over-ATM line-handler processes.

If all the lines in the path are down, look for a common problem such as a processor failure, a SWAN concentrator or Ethernet adapter down, lack of power to a bank of modems, or even a problem with the communications facilities.

If the line or lines are operational but the path is down, the problem is probably with the path procedures, or Layer 4 portion, of the Expand line-handler process.

Line(s) Down

If you identify that the problem is caused by a downed (nonoperational) line, take these steps:

• Unless you suspect a common problem, verify that the line is down by checking each individual instance of a line failure.

• Use SCF to verify that the line is in the STOPPED or STARTING states (unable to go to the START state).

• If the problem is multiple lines down and is caused by a SWAN concentrator or Ethernet adapter, document the problem and call your HP representative.

• Use SCF to obtain Layer 2 statistics and look for these:

• A high number of SABM and DISC frames, indicating that the link was repeatedly attempting to come online.

• A high number of SABMs sent, indicating that the other side of the line might have problems.

• Driver problems. A high number of BCC (FCS) errors, error frames, and/or line quality below 100 percent could indicate a noisy line, defective modem, or bad controller port.


Troubleshooting Adding Low-Speed Lines to a Multi-Line Path

Adding Low-Speed Lines to a Multi-Line Path

Adding more low-speed lines to a multi-line path can increase the number of OOS frames that a path must reassemble. The effect in this case is not on the buffer space used but on the total time taken for the sending Expand line-handler process to receive its ACK. As a result, the sending node might experience an increase in Layer 4 timeouts. The solution to this problem is to reconfigure the Expand line-handler process to have larger Layer 4 timeout (L4TIMEOUT modifier) and OOS timeout (OSTIMEOUT modifier) values.

Duplicate Node

The Expand subsystem identifies nodes primarily by their node (system) number. For any single network, each node must have a unique number in the range 0 through 254. It is possible to introduce a node into a network with a configured node number that is the same as that of a node that already exists in the network. The results of such a mistake vary depending on the network topology, but can be characterized by a few general symptoms, as described below:

• Applications that previously succeeded begin to fail with file-system error 201. All failing applications are attempting to access the same destination node.

• The number of NCPM packets increases steadily. NCPM packets can be observed by issuing an Expand subsystem SCF STATS PATH command.

• When an SCF INFO PROCESS $NCP, NETMAP command is issued, connections repeatedly alternate between connected and disconnected states.

The effect of a duplicate node number on user applications depends on the network topology and, in particular, on the size of the network. Those nodes closer (in terms of the routing algorithm) to the erroneously numbered node than to the correctly numbered node regard the invalid node as a better route and alter their routing tables and connect to the invalid node. Applications that were communicating with the valid node are not able to continue and might receive file-system error 201.

To resolve a duplicate node name and/or number problem, see Changing System Names and Numbers on page 18-23.

Note. The multi-line path does not need to be attached to the sending node. In a multiple-hop circuit, the problem can be caused by a multi-line path on the receiving node.

Note. Any one of the symptoms described above can be caused by factors other than a duplicate node in the network. However, the presence of all symptoms and their persistence is a good indication that a duplicate node number has been introduced.


A SCF Error Messages

This appendix contains error messages returned by the SCF subsystem when you run SCF commands. For other Expand network-related errors, see the Operator Messages Manual.

Expand Error 00001

Cause. You specified more than 30 object names in an SCF command.

Effect. The SCF command was not executed.

Recovery. Re-enter the command using fewer that 30 object names.

Expand Error 00002

Cause. The Expand line-handler process was not started, or a file-system error occurred.


Recovery. Start the Expand line-handler process, or correct the file-system error.

Expand Error 00003

Cause. This is a normal event.

Effect. The SCF command is not affected.

Recovery. No action is required.

Expand Error 00004

Cause. The token specified is not of the same type as expected.


Recovery. Examine the command, then enter the correct command.

EXPAND 00001 Too many object names. Object Name: object-name.

EXPAND 00002 Negative LH response. OBJNAME: object-name File system err #R##.

EXPAND 00003 Empty response.

EXPAND 00004 Token conflicted. OBJNAME: object-name TOKEN: token-name.

Expand Configuration and Management Manual — 529522-013A - 1

SCF Error Messages Expand Error 00005

Expand Error 00005

Cause. The subtype of an Expand line-handler process object name does not match the expected object type. For example, you might have entered a path logical device name after specifying a LINE object type in the SCF command.


Recovery. Re-enter the command with matching object types and object names.

Expand Error 00006

Cause. Because of an Expand internal error, tracing could not start.

Effect. Tracing has not started.

Recovery. File a detailed Product Report (TPR) immediately.

Expand Error 00007

Cause. Because of an Expand internal error, an invalid value was accepted.



Expand Error 00008

Cause. You entered the same attribute twice in the same command.


Recovery. Re-enter the command using the attribute only once.

EXPAND 00005 Object type and name mismatched. OBJNAME: object-name OBJTYPE: object-type.

EXPAND 00006 Encountered error when tracing EXPAND manager process. OBJNAME: object-name.

EXPAND 00007 INTERNAL ERR: Case value out of range.

EXPAND 00008 Duplicate Attribute attribute-list.



Expand Error 00009

Cause. The SCF command was rejected by the network control process ($NCP).


Recovery. Correct the file-system error, then re-enter the command.

Expand Error 00010

Cause. The local network control process ($NCP) received a bad network trace record from a remote system.

Effect. Tracing has stopped.


Expand Error 00011

Cause. The value entered in the command is not valid for the attribute, or the specified attribute is not valid for the object name.


Recovery. Re-enter the command using the correct value for the attribute.

Expand Error 00012

Cause. You specified 30 or more system names or system numbers in the command.


Recovery. Re-enter the command specifying fewer than 30 systems.

EXPAND 00009 Negative $NCP response. OBJNAME: object-name. File system err: #R##.

EXPAND 00010 INTERNAL ERR: Rcvd Bad Network trace from SYSTEM #R# to SYSTEM #R#.

EXPAND 00011 Invalid Attribute OR Attribute value: value for attribute-list.

EXPAND 00012 Too many systems selected.



Expand Error 00013

Cause. The system number specified in the SCF command is not recognized by the network control process ($NCP).


Recovery. Re-enter the command making sure to use the correct system number.

Expand Error 00014

Cause. All paths to the specified system are down.

Effect. Your local system cannot communicate with the specified system.

Recovery. Re-enter the command in a few minutes. If you still cannot communicate with the specified system, contact the system manager.

Expand Error 00015

Cause. The local system was just loaded. Its network routing table (NRT) is not yet updated.

Effect. The local system cannot communicate with any other systems.

Recovery. Re-enter the command in a few minutes.

Expand Error 00016

Cause. The SCF command was rejected by the Expand manager process ($ZEXP). This error might be caused by mismatched product versions between $ZEXP and the Expand line-handler process or the network control process ($NCP).


Recovery. Check the product versions of $ZEXP, the Expand line-handler process, and $NCP. Install the correct product versions if required, then re-enter the command.

EXPAND 00013 The SYSTEM system-number is not defined.

EXPAND 00014 All paths to the SYSTEM system-number are down.

EXPAND 00015 No known systems.

EXPAND 00016 Negative EXPAND manager response.



Expand Error 00017

Cause. The SCF command was rejected by the Expand manager process ($ZEXP). The information requested cannot be obtained from an older (down-version) system.



Expand Error 00018

Cause. The Expand line-handler process is configured with incorrect modifier values or the system does not have enough memory.

Effect. The Expand line-handler process is not operational.

Recovery. See the event log for more detailed error information, and respond accordingly. Use the OSM event viewer to display the event log.

Expand Error 00019

Cause. The SCF command was rejected by the Expand manager process ($ZEXP). SUPERPATH might be set to on ON only when L4EXTPACKETS is set to ON. L4EXTPACKETS might be set to OFF only when SUPERPATH is set to OFF.

Effect. The SCF command is not executed.

Recovery. Change L4EXTPACKETS to ON before you change SUPERPATH to ON or change SUPERPATH to OFF before you change L4EXTPACKETS to OFF.

Expand Error 00020

Cause. The SCF INFO PROCESS $NCP, SUPERPATH command was rejected because there is no active multi-CPU path.



EXPAND 00017 Not supported for a down-version system.

EXPAND E00018 Configuration error or Memory allocation failure.

EXPAND E00019 Extended packet format required for multi-CPU paths.

EXPAND E00020 No multi-CPU path active.



Expand Error 00021

Cause. The SCF INFO PROCESS $NCP, RPT command was rejected because there is no multi-CPU path connected to the specified system.



EXPAND E00021 System sysnum is not a multi-CPU path neighbor.


B Expand and WAN SCF Comparison

This appendix compares the commands provided by the SCF interface to the Expand subsystem with the commands provided by the SCF interface to the WAN subsystem. For a general comparison of the two SCF interfaces, see Section 14, Subsystem Control Facility (SCF) Commands.

Command ComparisonTable B-1 provides a command-to-command comparison of Expand SCF and WAN SCF commands and explains which command to use to perform a specific task.

Table B-1. Expand and WAN SCF Command Comparison (page 1 of 6)

Expand Subsystem SCF Command

WAN Subsystem SCF Command Command Function

ABORT ABORT Expand SCF:

• Use the ABORT LINE command to terminate activity on a selected Expand line.

• Use the ABORT PATH command to terminate activity on all the lines associated with a selected Expand path.

WAN SCF:

• The ABORT command does not operate on Expand line-handler processes or on the network control process ($NCP).

ADD Use the WAN subsystem ADD DEVICE command to create Expand line-handler processes and the network control process ($NCP).

Use the WAN subsystem ADD PROFILE command to create profiles for Expand line-handler processes and the network control process ($NCP).

Expand Configuration and Management Manual — 529522-013B - 1

Expand and WAN SCF Comparison Command Comparison

ALTER ALTER Expand SCF:

• Use the ALTER LINE and ALTER PATH commands to make temporary changes to attributes and attribute values for a selected Expand line-handler process.

• Use the ALTER PROCESS command to make temporary changes to attributes and attribute values for the network control process ($NCP).

WAN SCF:

• Use the ALTER DEVICE command to make permanent changes to modifier and modifier values for a selected Expand line-handler process or the network control process ($NCP).

Note: For more information, see ALTER Command Comparison on page B-7.

DELETE DELETE Expand SCF:

• Use the DELETE ENTRY command to remove a system name from the Network Routing Table (NRT).

WAN SCF:

• Use the DELETE DEVICE command to delete a selected Expand line-handler process or the network control process ($NCP) from the system.






INFO INFO Expand SCF:

• Use the INFO LINE command to display current Layer 2 attributes and attribute values for a selected Expand line-handler process.

• Use the INFO PATH command to display current Layer 4 attributes and attribute values for a selected Expand line-handler process.

• Use the INFO PROCESS command to display current attributes and attribute values for the network control process ($NCP).

• Use the DETAIL option with any INFO command to display additional attributes and attribute values.

WAN SCF:

• Use the INFO DEVICE command to display the primary and backup processors, type, record size, object file, and profile used by a selected Expand line-handler process or the network control process ($NCP).

• Use the DETAIL option to display device-specific modifiers and modifier values.

• Use the WAN subsystem INFO PROFILE command to display a list of the modifiers and modifier values contained in a certain profile. This command also displays the devices currently using a selected profile.

NAMES Use the WAN subsystem NAMES DEVICE command to display a list of the Expand line-handler processes configured to use the WAN manager process ($ZZWAN).






PRIMARY PRIMARY Expand SCF:

• Use the PRIMARY PROCESS command to cause the backup processor to become the primary processor and the primary processor to become the backup processor for a selected Expand line-handler process or for the network control process ($NCP).

WAN SCF:

• Use the PRIMARY SUBSYS command to change the preferred processor of the WAN manager process ($ZZWAN).

PROBE Use the Expand subsystem PROBE PROCESS command to display the current paths to one or more, or all, of the remote nodes within a network, from a specified node in the network.

START START Expand SCF:

• Use the START LINE command to initiate the operation of a selected Expand line.

• Use the START PATH command to start all the lines in a selected multi-line path.

WAN SCF:

• Use the START DEVICE command to start a selected Expand line-handler process or the network control process ($NCP).

Note: You must use the START DEVICE command to start an Expand line-handler process before using the Expand subsystem START LINE or START PATH command.

STATS • Use the Expand subsystem STATS LINE command to display Layer 2 statistical information for a selected Expand line.

• Use the STATS PATH commands to display Layer 3 and Layer 4 statistical information for a selected Expand path.

• Use the STATS PROCESS command to display statistical information about the network control process ($NCP).






STATUS STATUS Expand SCF:

• Use the STATUS LINE command to display the dynamic state, primary process ID (PPID), backup process ID (BPID), and other information about a selected Expand line.

• Use the STATUS PATH command to display the dynamic state, primary process ID (PPID), backup process ID (BPID), and number of lines in a selected Expand path.

• Use the DETAIL option with either STATUS command to display additional information.

WAN SCF:

• Use the STATUS DEVICE command to display the dynamic state and logical device (LDEV) number of a selected Expand line-handler process or the network control process ($NCP).

STOP STOP Expand SCF:

• Use the STOP LINE command to terminate the activity of a selected Expand line.

• Use the STOP PATH command to terminate the activity of all lines in multi-line path.

Note: You should use the STOP LINE or STOP PATH command before using the WAN subsystem STOP DEVICE command.

WAN SCF:

• Use the STOP DEVICE command to terminate the activity of a selected Expand line-handler process or the network control process ($NCP).

TRACE Use the Expand subsystem TRACE command to request the capture of target-defined data items, alter trace parameters, and end tracing.






VERSION VERSION Expand SCF:

• Use the VERSION PROCESS command to display the version level of the Expand manager process ($ZEXP), the network control process ($NCP), or a selected Expand line-handler process.

WAN SCF:

• Use the VERSION SUBSYS command to display the version level of the WAN manager process ($ZZWAN).





Expand and WAN SCF Comparison ALTER Command Comparison

ALTER Command ComparisonYou can use the SCF interface to the WAN subsystem to permanently change the value of any Expand modifier used by an Expand line-handler process or the network control process ($NCP). Expand modifiers are described in Section 16, Expand Modifiers.

Modifier-to-Attribute Comparison

Most—but not all—Expand modifiers have corresponding attribute names in Expand SCF. For example, the L4TIMEOUT modifier corresponds to the L4TIMEOUT Expand SCF attribute. You can use the SCF interface to the Expand subsystem to temporarily change modifiers that have corresponding SCF attribute names.

Profile Modifiers Only

Certain Expand 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. These are the modifiers:

SCF Attributes Only

Certain Expand SCF attributes do not correspond to Expand modifiers and therefore can be changed only by using the SCF interface to the Expand subsystem. These are the attributes:

Note. Permanent changes remain across system loads; temporary changes do not remain across system loads.

ALGORITHM AUTOMATICMAPTIMER

EXTMEMSIZE FRAMESIZE

INTERFACE_RS232 INTERFACE_RS422

STARTUP_OFF STARTUP_ON

CLBDWNLOADRETRIES TIMERINACTIVITY

CLBDWNLOADTIMER TIMERPROBE

CLBIDLETIMER TIMERRECONNECT

DSRTIMER MSG 43 ON|OFF

IDLETIMEOUT MSG 46 ON|OFF

RETRYPROBE MSG 48 ON|OFF

TIMERBIND MSG 49 ON|OFF


Expand and WAN SCF Comparison Altering Timeout Periods

Altering Timeout Periods

Certain Expand SCF attributes are used to set a timeout period (for example, the OSTIMEOUT attribute specifies the Expand out-of-sequence packet timeout period). These Expand SCF attributes accept different units of time than the Expand modifiers with which they correspond. As a result, you must specify different values to set the same timeout period when using the Expand subsystem SCF ALTER and WAN subsystem SCF ALTER commands.

These are the affected Expand SCF attributes and Expand modifiers:

• L2TIMEOUT• L4TIMEOUT• OSTIMEOUT• ABORTTIMER• CONNECTTIME

Expand SCF Time Units

The Expand SCF attributes are set using time intervals. A time interval is specified in this format:

HH:MM:SS:hh

HH (hours) is an integer in the range 0 through 24. MM (minutes) and SS (seconds) are integers in the range 0 through 60. hh (hundredths of a second) 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; 1.00 is 1 second; 0.25 is 25 hundredths of a second; and so on.

This Expand subsystem SCF ALTER LINE command sets the L4TIMEOUT attribute to 20 seconds:

alter path $line2, l4timeout 20.00

WAN SCF Time Units

The Expand modifiers are set in one-hundredth of a second increments. (For example, 1000 is equal to 10 seconds.)

This WAN subsystem SCF ALTER DEVICE command sets the L4TIMEOUT modifier to 20 seconds:

alter device $zzwan.#line1, l4timeout 2000


Glossaryactive connect request. The default connect request method used by an Expand line-

handler process when it tries to establish an end-to-end connection. When an Expand-over-NAM line-handler process issues an active connect request, the network access method (NAM) process tries to initiate a connection. When an Expand-over-IP or Expand-over-ATM line-handler process issues an active connect request, it sends a Connect Command frame to the remote Expand-over-IP or Expand-over-ATM line-handler process. See also passive connect request and network access method (NAM).

adapter. See ServerNet adapter.

adjacent system. See Expand neighbors.

aggregate time factor. The combination of the time factors (TFs) of all the Expand line-handler processes in a multi-CPU path. See also time factor (TF) and multipacket frame.

application message size. The number of data bytes sent to an Expand line-handler process by a higher-level process. The relationship between the Expand frame size and the application message size can have a major effect on Expand line-handler process and processor overhead. See also Expand frame.

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.

best-path route. The route with the fastest transit time. The best-path route is the route with the lowest time factor (TF) and lowest hop count (HC). If two or more routes have the same TF and HC, the first path up after the system is started is the best-path route. See also best-path routing, time factor (TF), and hop count (HC).

best-path routing. A routing scheme used by the Expand subsystem to ensure that data travels between two nodes using the fastest possible route. See also best-path route.

bind request. A type of request issued by Expand-over-NAM and Expand-over-ServerNet line-handler processes to access a subdevice on a network access method (NAM) process. A bind request is roughly equivalent to an OPEN procedure.

buffer pool. Memory that is issued by the Expand line-handler process to buffer incoming and outgoing messages as they are sent and received from the line buffer. See also line buffer.

Expand Configuration and Management Manual — 529522-013Glossary - 1

Glossary congestion control

congestion control. A feature that allows you to control system resources to avoid network bottleneck and resource contention situations. You can enable or disable congestion control using the Expand subsystem SCF ALTER PATH command or the WAN subsystem SCF ALTER DEVICE command.

control block pool. A portion of the Expand line-handler process data space that contains control blocks. A control block is allocated for each node in the network.

direct-connect line-handler process. An Expand line-handler process that 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 and switched-line facilities, private facilities, and Transmission Group 1 (T1) facilities.

distance vector (DV) message. An Expand network control process ($NCP) message that gives the time factor (TF) and hop count (HC) from the system originating the distance vector (DV) message to the node named in the message.

DV message. See distance vector (DV) message.

effective time factor (ETF). 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 ETF indicates the inverse proportion of traffic that should be sent over the path compared to an unloaded path with a TF of 1. Therefore, a path with a TF of 6 reports an ETF of 12 when it is half loaded. See also multipacket frame.

End-to-End protocol. An HP proprietary protocol implemented by the Expand line-handler process that provides functions similar to some of those defined by the OSI Session Layer, Transport Layer, and Network Layer.

ETF. See effective time factor (ETF).

Ethernet 4 ServerNet Adapter (E4SA). A ServerNet adapter for Ethernet local area networks (LANs) that contains four Ethernet ports.

Expand frame. A unit of data, consisting of control information and user data, that is transmitted by an Expand line-handler process. An Expand line-handler process fragments application messages into Expand frames. The size of an Expand frame is determined by the FRAMESIZE modifier. The frame size must be the same for every Expand line-handler process in the network.

Expand line-handler process. A process pair that handles incoming and outgoing Expand messages and packets. An Expand line-handler process handles direct links and also binds to other processes via the network access method (NAM) interface to support Expand-over-X.25, Expand-over-ServerNet, and Expand-over-SNA links. The Expand-over-IP line-handler process communicates with a NonStop TCP/IP process through the shared memory of the QIO subsystem. The Expand-over-ATM line-handler process communicates with the Asynchronous Transfer Mode (ATM) subsystem through the


Glossary Expand line-handler process pair

shared memory of the QIO subsystem. See also network access method (NAM) and NETNAM protocol.

Expand line-handler process pair. The Expand line-handler processes at the source and destination node on a multi-CPU path. Expand line-handler processes at each source and destination node on a multi-CPU path are paired to guarantee message order; all messages between that source and destination node are sent through this Expand line-handler process pair. $NCP periodically runs a rebalancing algorithm that reconsiders the pairings of Expand line-handler processes on each multi-CPU path. See also multipacket frame and rebalancing algorithm.

Expand manager process. A process, named $ZEXP, that provides the interface between the Expand subsystem and the Distributed System Management (DSM) Subsystem Control Point (SCP).

Expand multi-CPU feature. A feature of the Expand subsystem that enables 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. The Expand multi-CPU feature significantly increases the maximum throughput of an Expand path, especially for Expand-over-IP connections. See also multipacket frame.

Expand neighbors. Two adjacent Expand nodes that have a path between them.

Expand-over-ATM line-handler process. An Expand line-handler process that uses the Asynchronous Transfer Mode (ATM) subsystem to provide connectivity to an ATM network.

Expand-over-IP line-handler process. An Expand line-handler process that uses the NonStop TCP/IP subsystem to provide connectivity to an Internet Protocol (IP) network.

Expand-over-NAM line-handler process. An Expand line-handler process that uses the NETNAM protocol to access the network access method (NAM) interface provided by an X25AM line-handler process or a SNAX/APN line-handler process.

Expand-over-ServerNet line-handler process. An Expand line-handler process that uses the NETNAM protocol to access the network access method (NAM) interface provided by the ServerNet monitor process, $ZZSCL. The Expand-over-ServerNet process handles incoming and outgoing Expand messages and packets going outside a ServerNet cluster and handles security-related messages within the cluster.

Expand-over-SNA line-handler process. An Expand line-handler process that uses the NETNAM protocol to access the network access method (NAM) interface provided by a SNAX/APN line-handler process.

Expand-over-X.25 line-handler process. An Expand line-handler process that uses the NETNAM protocol to access the network access method (NAM) interface provided by an X25AM line-handler process.


Glossary Expand packet

Expand packet. See Expand frame.

Expand priority. The priority of an Expand message. The Expand priority is based on the priority level of the application process that created the message, unless the SETMODE 71 procedure is used.

frame. See Expand frame.

global variables space. A portion of the Expand line-handler process data space that contains Expand 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.

HC. See hop count (HC).

HDLC Extended Mode protocol. See High-Level Data Link Control (HDLC) Extended Mode protocol.

HDLC Normal protocol. See High-Level Data Link Control (HDLC) Normal protocol.

High-Level Data Link Control (HDLC) Extended Mode protocol. The protocol used by the satellite-connect line-handler process. 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. See also High-Level Data Link Control (HDLC) Normal protocol.

High-Level Data Link Control (HDLC) Normal protocol. The protocol used by the direct-connect line-handler process. The direct-connect 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. See also High-Level Data Link Control (HDLC) Extended Mode protocol.

hop count (HC). The number of intervening nodes on a route. HC is used to determine the best path route: if two alternative routes have the same time factor (TF), the route with the lowest HC is the best route. See also best-path route and time factor (TF).

Layer 2. A term that is used to refer to the Data Link Layer of the Open Systems Interconnection (OSI) Reference Model. Layer 2 defines rules for transmission on the physical medium. Direct-connect and satellite-connect Expand line-handler processes provide the High-level Data Link (HDLC) protocol at Layer 2. Expand-over-NAM line-handler processes use the Layer 2 services provided by either the SNAX/APN or X25AM subsystems. Expand-over-ServerNet line-handler processes use the Layer 2 services provided by the ServerNet monitor process, $ZZSCL. Expand-over-IP line-handler processes use the Layer 2 services provided by NETIP protocol. Expand-over-ATM line-handler processes use the Layer 2 services provided by the NETATM protocol. The Expand line-handler process’s Data Link Layer, or line functions,


Glossary Layer 3

corresponds to the LINE object referred to by the Expand Subsystem Control Facility (SCF) interface.

Layer 3. A term that is used to refer to the Network Layer of the Open Systems Interconnection (OSI) Reference Model. Layer 3 governs the switching and routing of information between systems in the network and is responsible for error checking and recovery. The Expand line-handler process’s Network Layer, or path functions, corresponds to the PATH object referred to by the Expand Subsystem Control Facility (SCF) interface.

Layer 4. A term that is used to refer to the Transport Layer of the Open Systems Interconnection (OSI) Reference Model. Layer 4 accepts data from the OSI Session Layer (Layer 5) and passes it to the OSI Network Layer (Layer 3). Layer 4 provides end-to-end data integrity between processes and checks that messages received are correct. The Expand line-handler process’s Layer 4, or path functions, corresponds to the PATH object referred to by the Expand Subsystem Control Facility (SCF) interface.

Layer 4 send window. A data structure that determines how many Expand packets are sent before an acknowledgment is required on a single end-to-end (Layer 4) connection.

line. A single physical connection between two systems. See also route and path.

line buffer. A portion of the Expand line-handler process data space used to buffer incoming and outgoing messages after they have been formatted into packets by the Expand line-handler process.

line function. One of the two functions of an Expand line-handler process. A single-line Expand line-handler process performs both line and path functions with a single logical device. A multi-line path requires a logical device to manage the path function and a separate logical device for each line in the path.

line handler. See Expand line-handler process.

line logical device. A logical device that manages a line in a multi-line path. One line logical device is required for each line in a multi-line path.

LNP. See logical network partitioning.

load. (1) To transfer the operating system image or an application from a disk into a computer’s memory so that the operating system or application can run. (2) To insert a tape into a tape drive, which prepares it for a tape operation (read or write).

load balancing. A term used to refer to the balancing of traffic on multi-CPU paths. $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 process pairs. You can initiate an immediate rebalance using the SCF RESET PROCESS command or specify when rebalancing should occur


Glossary load factor

using the SCF ALTER PROCESS command. See also rebalancing algorithm and Expand line-handler process pair.

load factor. The ratio between a path’s effective time factor (ETF) and its base time factor (TF). See also effective time factor (ETF).

local system. A term used to refer to the system to which your terminal is directly connected.

logical device name. The name assigned to an input-output process (IOP) during its configuration.

logical device number. A number that identifies a particular input-output (I/O) device in the system.

logical network partitioning. A NonStop TCP/IPv6 feature that allows you to divide the system into separately-addressed IP subnetworks whereby applications only have access to a defined set of network interfaces (IP addresses).

logical unit (LU). In the IBM Systems Network Architecture (SNA), a port by which an end user accesses the network.

LU. See logical unit (LU).

maps exchange. A periodic sharing of network maps information. You can specify a five-minute interval exchange by setting the network control process modifier AUTOMATICMAPTIMER. See also distance vector (DV) message.

Measure. A tool used for monitoring the performance of HP systems. Measure can be used in an Expand network to determine if the network is contributing to performance problems.

modified split horizon (MSH). The default routing algorithm provided by the Expand subsystem. The main advantage of MSH is efficiency: it requires less processing time than the split horizon (SH) algorithm and avoids loop routing. The main disadvantage of MSH is that the network might experience temporary discontinuity. See also split horizon (SH).

MPT. See multiple path table (MPT).

MSH. See modified split horizon (MSH).

multi-CPU path. 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 is configured in a different processor. See also Expand multi-CPU feature.

multi-line path. A path between two neighbor systems that consists of more than one physical line. You can configure as many as eight parallel lines between the same two


Glossary multipacket frame

systems. The Expand subsystem will simultaneously transmit data over all the lines in the path, increasing overall bandwidth. The Expand subsystem also automatically reroutes data over remaining lines if one or more lines fail. See also line, path, and route. Contrast single-line path.

multipacket frame. A data structure that contains multiple Expand packets. The multipacket frame feature is enabled using the PATHBLOCKBYTES modifier. It should be enabled when you are sending many small concurrent requests. Contrast variable packet size.

multiple path table (MPT). A table that resides in each processor in each node in an Expand network. The network routing table (NRT) contains an entry which points to the MPT. The MPT contains information bout each multi-CPU path in the system. MPT entries are assigned to specific multi-CPU paths by $NCP. See also multipacket frame.

NAM. See network access method (NAM).

$NCP. See network control process (NCP).

neighbor systems. See Expand neighbors.

NETATM. The protocol used by Expand-over-ATM line-handler processes to provide a QIO-based interface to send Layer 2 frames over Asynchronous Transfer Mode (ATM) networks.

NETIP. The protocol used by Expand-over-IP line-handler processes to provide a QIO-based interface to send Layer 2 frames over Internet Protocol (IP)-based networks.

NETNAM protocol. The protocol used by an Expand line-handler process to communicate with a network access method (NAM). See also network access method (NAM).

network. Two or more computer systems (nodes) that are connected so that they can exchange information and share resources.

network access method (NAM). The interface through which an Expand-over-NAM line-handler process communicates with an X25AM line-handler process or a SNAX/APN line-handler process, and through which an Expand-over-ServerNet line-handler process communicates with the ServerNet monitor process ($ZZSCL).

network control process (NCP). A process pair, named $NCP, that runs in each system of an Expand network. $NCP is responsible for establishing and terminating system-to-system connections, maintaining network-related system tables (including the network routing table, NRT), calculating the most efficient way to transmit data to other systems in the network, monitoring and logging changes in the status of the network and its systems, informing $NCPs at neighbor systems of changes in line or Expand line-handler process status, and aborting pending requests when all paths go down. $NCP uses the services of the network utility process, $ZNUP. See also network routing table (NRT) and network utility process.


Glossary network routing table (NRT)

network routing table (NRT). A table that resides in each processor in each system in the network. The NRT associates each destination system with the logical device (LDEV) number of the best-path route Expand line-handler process to use to send messages to that system. See also best-path route and network control process (NCP).

network topology. The pattern of interconnection of systems in a network. Common network topologies include star, tree, ring, bus, mesh, and mixed.

network utility process. A NonStop Kernel input-output process (IOP), named $ZNUP, which is used by the network control process ($NCP). $ZNUP answers requests that require waits 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.

node. A uniquely identified computer system connected to one or more other computer systems in a network.

NonStop Cluster Switch. An assembly consisting of a ServerNet II Switch, an uninterruptible power supply (UPS), and an AC transfer switch. The NonStop cluster switch enables the routing of ServerNet messages across an external fabric of a ServerNet cluster. The assembly can be packaged in a switch enclosure or in a 19-inch rack.

NRT. See network routing table (NRT).

object type. A category of SCF objects to which a specific object belongs. There are four Expand SCF object types: PROCESS, PATH, LINE, and ENTRY.

Open Systems Interconnection (OSI). A seven-layer network-architecture model defined by the International Organization for Standardization (ISO). The two lower layers deal with the physical connections and their protocols. The five upper layers deal with network services, such as network file transfers and accessing remote databases.

operator message. A message, intended for an operator, that describes a significant event on a NonStop server. An operator message is the displayed-text form of an Event Management Service (EMS) event message.

OSI. See Open Systems Interconnection (OSI).

out-of-sequence (OOS) buffer. A portion of the Expand line-handler process data space used to buffer packets that are received out of sequence by the Expand line-handler process. Expand allocates 32767 words to the OOS buffer. See also out-of-sequence (OOS) packets.

out-of-sequence (OOS) packets. Packets that are destined for a process at the local system but that are not received in the same order in which they were sent.


Glossary packet

packet. A block of information that contains fields for addressing, sequencing of information, priority indicators, and a portion of a message or an entire message. See also Expand frame.

packet header. The portion of an Expand frame that contains control information added by the Expand line-handler process. By default, D20 and later Expand frames use an extended packet header format of 64 bytes.

passive connect request. A connect method that can be used by an Expand line-handler process when it tries to establish an end-to-end connection. When an Expand-over-NAM line-handler process issues a passive connect request, the network access method (NAM) waits for an incoming connect request. When an Expand-over-IP or Expand-over-ATM line-handler process issues a passive connect request, it waits for an incoming Connect Command frame from the remote Expand-over-IP or Expand-over-ATM line-handler process. See also active connect request and network access method (NAM).

passthrough routing. A routing scheme used by the Expand subsystem that permits intermediate nodes to route, or passthrough, data packets to the destination system. This scheme reduces the number of lines required between systems because systems do not have to be directly connected.

passthrough traffic. Packets received from a remote node that are destined for another remote node. See also passthrough routing.

path. One or more lines between two adjacent nodes. See also route and best-path route.

path function. One of the two functions of an Expand line-handler process. A single-line Expand line-handler process performs both path and line functions with a single logical device. A multi-line path requires a logical device to manage the path function and a separate logical device for each line in the path.

path logical device. A logical device that manages the path function for a multi-line path.

persistence. The capability of a generic process to restart automatically if it was stopped abnormally.

persistence manager. A process named $ZPM that starts generic processes and manages their persistence.

physical unit (PU). In the Systems Network Architecture (SNA), the component that manages and monitors the resources of a node.

profile. A disk file containing modifiers and default values. On NonStop NS-series servers, a profile is required when configuring a device. HP provides profiles for the different types of Expand line-handler processes. You can create your own customized profile using the SCF interface to the WAN subsystem (ADD PROFILE command). You can also alter profile modifier values for a particular device using the SCF interface to the


Glossary profile modifier

WAN subsystem (ADD DEVICE and ALTER DEVICE commands). Profiles are provided on NonStop NS-series servers only.

profile modifier. A configuration modifier in a profile. See also profile.

PU. See physical unit (PU).

PVC. See persistence.

QIO. A mechanism for transferring data between processes through a shared memory segment. The QIO subsystem is preconfigured and started during the system load sequence.

QIOMON. The QIO Monitor process. QIOMON is responsible for creating a shared data segment, monitoring clients that use the segment (such as Expand line-handler processes), and performing functions needed for segment management.

rebalancing algorithm. An algorithm that is run by $NCP that reconsiders pairings of Expand line-handler processes on each multi-CPU path. If the load is unbalanced, $NCP changes some Expand line-handler process pairs. The goal of the rebalancing algorithm is to make the average load factors (LFs) of all the paths in the multi-CPU path close to equal. See also multipacket frame, Expand line-handler process pair, and load balancing

REMOTEPASSWORD command. A TACL command that is used to create remote passwords. You must create one remote password for the local system and one remote password for each remote system on which a user has an account.

remote system. A term used to refer to the systems in your network other than your local system. See also local system.

reverse pairing table (RPT). An entry in the multiple path table (MPT). 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. See also multipacket frame and multiple path table (MPT).

route. The sequence of paths that data follows when traveling between source and destination nodes. There is only one active route at a time between communicating nodes. See also path and best-path route.

RPT. See reverse pairing table (RPT).

satellite-connect line-handler process. An Expand line-handler process that implements the satellite-efficient version of the High-Level Data Link Control (HDLC) protocol, HDLC Extended Mode. This type of Expand line-handler process is provided for use with satellite connections but can also be used to manage terrestrial lines.


Glossary ServerNet adapter

ServerNet adapter. A component that connects peripheral devices to the rest of the system through a ServerNet bus interface (SBI).

ServerNet cluster. ServerNet clusters enable multiple NonStop NS-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.

ServerNet cluster monitor process. The manager process, called $ZZSCL, for the ServerNet cluster subsystem on NonStop NS-series servers. $ZZSCL is responsible for maintaining configuration information about a ServerNet cluster.

SH. See split horizon (SH).

single-line path. A path that consists of one line. See also line, path, and route. Contrast multi-line path.

split horizon (SH). An alternative routing algorithm provided by the Expand subsystem. The main advantage of SH is that alternate paths are immediately known (temporary discontinuity never occurs). The main disadvantage of SH is that it increases the occurrence of loop routing. See also modified split horizon (MSH).

stack. A portion of the Expand line-handler process data space. The Expand subsystem allocates 700 words to the stack.

superpath. In Expand, the SUPERPATH modifier enables the multi-CPU path feature. See also multipacket frame.

TF. See time factor (TF).

throughput. The amount of traffic that can be handled by an Expand line-handler process.

time factor (TF). A number assigned to a line, path, or route to indicate efficiency in transporting data. The lower the TF, the more efficient the line, path, or route.

variable packet size. A feature that allows Expand nodes to send packets that can exceed the size of a normal Expand packet. The variable packet size feature is enabled using the PATHPACKETBYTES modifier. It should be enabled when you are sending large blocks of data. Contrast multipacket frame.

$NCP. The process name of the network control process.

$ZZCIP. The management process for the Cluster I/O Protocols subsystem.

$ZEXP. The process name of the Expand manager process.

$ZNET. The process name of the default Subsystem Control Point (SCP).

$ZNUP. The process name of the network utility process.


Glossary $ZPM

$ZPM. The process name of the persistence manager process.

$ZZKRN. The process name of the Kernel subsystem manager process.

$ZZLAN. The process name of the ServerNet LAN systems access (SLSA) subsystem manager process.

$ZZSCL. The process name of the ServerNet monitor process.

$ZZTCP. The management process for the NonStop TCP/IPv6 subsystem.

$ZZWAN. The process name of the wide area network (WAN) subsystem manager process.


Index

AABORT command 14-8/14-9ABORT LINE command 18-27ABORT PATH command 18-27ABORTTIMER attribute

ALTER PROCESS $NCP command and 14-21

INFO PROCESS $NCP command and 14-54

ABORTTIMER modifier 6-4, 17-28ACK 17-15ACTIVATE command 14-9ACTIVATE PROCESS $NCP 18-28Active connect request 17-51, 17-54, 17-60ADD DEVICE command 18-20ADDRESS attribute, INFO LINE command and 14-34AFTERMAXRETRIES attribute

ALTER LINE command and 14-14

INFO LINE command and 14-37, 14-39, 14-44, 14-48

AFTERMAXRETRIES_DOWN modifier 16-4, 17-52, 17-55, 17-60AFTERMAXRETRIES_PASSIVE modifier 16-4, 17-52, 17-55, 17-60ALGORITHM modifier 6-5, 14-54ALTER DEVICE command 14-10, 17-23ALTER LINE command 14-12, 14-20, 17-23ALTER PATH command 14-11/14-12ALTER PROCESS $NCP command 14-21/14-23, 18-28Altering several lines 14-18Altering several paths 14-12ALTTCPIP attribute 20-14Application message size

effect on performance of 19-7

Expand subsystem overhead and 19-8

Applications, writing network 2-2ASAP 20-10

ASSOCIATEDEV attributeALTER LINE command and 14-14

INFO LINE command and 14-36, 14-40, 14-42, 14-44, 14-46, 14-49

ASSOCIATEDEV modifier 16-4, 20-18ASSOCIATESUBDEV attribute


ASSOCIATESUBDEV modifier 16-5Asynchronous Transfer Mode (ATM)

addresses 9-6

subsystem 9-3, 17-58

ATM 3 ServerNet adapter 9-3, 17-6ATM addresses 9-6, 17-59ATM protocol direct service access point (ATMSAP) 9-5ATM subsystem 9-3, 17-58

See also Asynchronous Transfer Mode (ATM) subsystem

ATM3SA 8-6, 9-3, 17-6ATMSAP connections 9-1, 17-58/17-59ATMSEL modifier 16-5AUTOLOAD attribute, INFO LINE command and 14-34AUTOMATICMAPTIMER attribute, INFO PROCESS $NCP command and 14-53AUTOMATICMAPTIMER modifier 6-5, 17-27AUTOREBAL attribute



AUTOREBALTIME attributeALTER PROCESS $NCP command and 14-22


Expand Configuration and Management Manual — 529522-013Index - 1

Index B

BBCC Errors, STATS LINE command and 14-94Best-path routing 2-7, 17-24, 20-33Bind requests 17-51Bottlenecks, avoiding 17-69Buffer errors, STATS LINE command and 14-94Buffer pool

description of 17-47

EXTMEMSIZE 17-48

inadequate allocation of 20-12

insufficient space in 17-20

Buffers 17-47Bulk transfers 19-5Bus topology 3-14

CCalculating a path time factor, formula 17-22CALLTYPE_ATMSAP modifier 16-5CALLTYPE_PVC modifier 16-5CALLTYPE_SVC modifier 16-5Cancel request packet 17-15CIP

selecting as environment 1-10

CIP process 8-4CIPSAM process

associating the line-handler with 1-10

CLBDWNLOADRETRIES attributeALTER LINE command and 14-15

INFO LINE command and 14-35

CLBDWNLOADTIMR attributeALTER LINE command and 14-15


CLBIDLETIMER attributeALTER LINE command and 14-15


CLBIDLETIMER modifier 16-6CLIM 8-6

CLIPINFO LINE command and 14-35

STATS LINE command and 14-94

CLOCKMODE attributeALTER LINE command and 14-14


CLOCKMODE_DCE modifier 16-6CLOCKMODE_DTE modifier 16-6CLOCKSPEED attribute



CLOCKSPEED modifier 16-6Commands, SCF

See individual command names

Communications methods 2-5/2-6, 3-1/3-4Components, Expand subsystem 17-2COMPRESS attribute

ALTER PATH command and 14-11

INFO PATH command and 14-25/14-26

Compression, data 17-40COMPRESS_OFF modifier 16-7COMPRESS_ON modifier 16-7, 17-40Concentrator manager (ConMgr) processes 20-16Configuration modifiers

See individual modifier names

Congestion control feature 19-10benefits of 3-12

computing ETF 17-25

configuring 17-69/17-71

L4CONGCTRL_ON modifier for 7-12, 10-13, 11-15, 12-13

overview 19-9

Congestion, symptoms of 20-33ConMgr processes 20-16CONN ACK 17-13CONN REQ 17-13CONN RSP 17-13CONN RST 17-14Connection acknowledgment packets 17-13


Index D

Connection establishmentExpand-over-ATM 17-59

Expand-over-FOX 17-50

Expand-over-IP 17-54

Expand-over-NAM 17-50

Connection requestsactive 17-51, 17-54, 17-60

packets 17-13

passive 17-52, 17-55, 17-60

Connection reset packets 17-14Connection response packets 17-13CONNECTS option 14-50, 14-57CONNECTTIME attribute



CONNECTTIME modifier 6-5CONNECTTYPE attribute

ALTER LINE command 14-14


CONNECTTYPE_ACTIVEANDPASSIVE modifier 16-7, 17-51, 17-54, 17-60CONNECTTYPE_PASSIVE modifier 16-7, 17-52, 17-55, 17-60CONNEP attribute, INFO LINE command and 14-44CPU matching 17-32, 19-17, 19-19CPUS command 20-11

DData compression

effect on frame size of 19-12


Data compression, description of 17-40Data encryption 2-11, 18-12Data Link Layer, Expand functions at 17-11Data packet

acknowledgment packets 17-15

enquiry packets 17-15

Data space 17-46

DATAPAC 3-2DATEX-P 3-2Dedicated lines, benefits and disadvantages of 3-1DELAY attribute


INFO LINE command and 14-31, 14-33, 14-36, 14-39, 14-41, 14-43, 14-46, 14-48

DELAY modifier 16-8DELETE DEVICE command 18-20DELETE ENTRY $NCP command 14-23/14-24, 18-26DESTATMADDR attribute, ALTER LINE command and 14-14DESTATMADDR modifier 16-8DESTIPADDR attribute



DESTIPADDR modifier 16-8, 16-9DESTIPPORT attribute



DESTIPPORT modifier 16-9Device type


See also Subtypes

Devices, WAN 5-4Diagrams, creating network 3-15Direct-connect line-handler process


features of 3-1, 17-3

DISC frames 20-35Disk files, naming convention for 18-2Distance vector (DV) messages 17-27Distributed applications 2-7Distributed networks 2-7DOWNIFBADQUALITY attribute


INFO LINE command and 14-33, 14-39, 14-43


Index E

DOWNIFBADQUALITY modifier 16-9Driver problems 20-35DSRTIMEOUT attribute, INFO LINE command and 14-35DSRTIMER attribute



DV messages 17-27

EEffective time factor (ETF), displaying 18-14, 20-12End-to-End protocol


resolving problems with 20-12

ENQ 17-15Error Frames, STATS LINE command and 14-94Error messages A-1/A-6Errors

BCC 20-32, 20-35

FCS 20-32, 20-35

file-system 20-7

ETF, displaying 18-14, 20-12Ethernet 17-65, 20-14Ethernet adapters, redundancy 8-4Ethernet failover 8-5Event Management Service (EMS)

features of 20-10

messages produced by 20-1

Expand frame size 19-1, 19-3, 19-6, 19-12Expand line-handler processes

adding and deleting 18-20

changing modifiers for 18-21

data space allocated to 17-46

functions of 17-2

global variables space allocated to 17-47

limitations of 3-14

line buffer space allocated to 17-47

number supported 4-2


stack space allocated to 17-47

starting 18-22

stopping 18-23

switching primary and backup processors for 18-28

types of 17-3/17-5

Expand manager processfunctions of 17-7

starting 5-4

Expand multi-CPU feature 7-12, 8-33, 9-19, 10-13, 11-15

See also Multi-CPU paths

Expand packet format 19-9Expand subsystem overhead 19-8Expand-over-ATM


using variable packet size feature with 19-6

Expand-over-ATM line-handler processconfiguring 9-1/9-21


Expand-over-IPcongestion control for 19-10


TXWINDOW modifier for 19-10

using variable packet size feature with 19-6

Expand-over-IP line-handler processconfiguring 8-1/8-34


Expand-over-NAM line-handler processSNAX/APN connections 17-4

tuning 19-11

X25AM connections 17-4

Expand-over-ServerNet line-handler process


Expand-over-SNA line-handler processconfiguring 11-1/11-17



Index F

Expand-over-X.25 line-handler processconfiguring 10-1/10-16


Expand-over-X.25, resolving problems with 20-18Expand-to-ATM interface 17-58Expand-to-IP interface 17-53Expand-to-NAM interface 17-49EXPLH_EXPNCP_LINE_STATUS message 17-24Extended packet format 19-6EXTMEMSIZE modifier 16-9

FFault-tolerance 2-8File identifier 18-2File system 2-2File transfer, network 2-1File Utility Program (FUP) 2-1File-system errors 20-7FILTER command 15-6FIND command 15-7FIRMUP procedure 20-15FLAGFILL attribute



FLAGFILL_OFF modifier 16-10FLAGFILL_ON modifier 16-10Flow control 17-10Frame size

See Expand frame size

FramesDISC 20-35

displaying information about 20-32

RR 20-32

SABM 20-35

supervisory 20-32

FRAMESIZE attributeINFO LINE command and 14-31/14-33, 14-36/14-38, 14-41/14-42, 14-46/14-47

INFO PROCESS $NCP command and 14-53/14-55

FRAMESIZE modifier 6-6, 16-10, 17-66/17-67, 19-1, 19-3, 19-5/19-6FROM command 15-8Fully qualified file name 18-2FUP 2-1FUP SECURE command 2-11

GGigabit Ethernet 4-port ServerNet adapter (G4SA) 8-6, 10-3Global user IDs 18-7Global variables space 17-47

HHDLC

Extended Mode 2-5, 3-2, 17-11

Normal 2-5, 17-11

HEX command 15-8Hierarchical networks 2-7HIGHPIN default for line-handlers 14-10High-level Data Link Control protocol

Extended Mode 2-5, 3-2, 17-11

Normal 2-5, 17-11

Hops 14-63Host computers 2-7

IIDLETIMEOUT attribute



Incoming traffic flow 17-42INFO DEVICE command 18-15, 20-11INFO LINE command 14-31/14-47, 18-17INFO PATH command 14-25/14-29, 18-18INFO PROCESS command 18-15, 20-5, 20-11, 20-32INFO PROCESS $NCP command 14-50/14-70, 18-13, 20-8


Index K

INFO PROFILE command 18-15INFO SU command 20-18Information frames (I-frames) 20-32Information frames, STATS LINE command and 14-92Interactive network access 2-1INTERFACE attribute



INTERFACE_RS232 modifier 16-10INTERFACE_RS422 modifier 16-10Internet Protocol (IP) 17-53IP network routes, redundancy in 8-4IP networks 3-4IPADDRESS attribute 20-17IPv4

addresses 8-24

display format 14-37

mode 8-14

IPv6addresses 8-24

display format 14-37

lines 8-1

SUBNETs 8-11

IPv6-to-IPv4 tunnel, configured 8-28, 8-30IPVER attribute



IPVER_IPV4 modifier 16-11IPVER_IPV6 modifier 16-11IPVER_IPV6 parameter 1-11

KKERNELCODE file 20-17Kernel, NonStop 2-2

LL2DISCARDONRESET attribute, ALTER LINE command and 14-14

L2DISCARDONRESET_OFF modifier 16-11L2DISCARDONRESET_ON modifier 16-11L2PROTOCOL attribute, INFO LINE command and 14-32, 14-38, 14-42, 14-47L2RETRIES attribute



L2RETRIES modifier 16-11L2TIMEOUT attribute



L2TIMEOUT modifier 16-12L3WINDOW modifier 10-14, 13-18L4CONGCTRL attribute


INFO PATH command and 14-27

L4CONGCTRL_OFF modifier 8-32, 9-18, 16-13, 17-71L4CONGCTRL_ON modifier 7-12, 8-32, 9-18, 10-13, 11-15, 16-13, 17-71, 19-10L4EXTPACKETS attribute



L4EXTPACKETS_OFF modifier 9-19, 16-14, 16-15, 17-68L4EXTPACKETS_ON modifier 9-19, 16-14, 19-6L4RETRIES attribute



L4RETRIES modifier 16-15L4SENDWINDOW attribute



L4SENDWINDOW modifier 16-15, 17-21L4TIMEOUT attribute


INFO PATH command and 14-25, 14-27

L4TIMEOUT modifier 10-13, 11-15, 16-16


Index M

LABEL command 15-9Latency 19-4, 19-6Layer 1, Expand functions at 17-11Layer 2

displaying frames at 14-92

Expand functions at 17-11

statistics, analyzing 20-32

windowing, effect on performance of 19-10

Layer 3, Expand functions at 17-10Layer 4

Expand functions at 17-10

retries at 17-15

send window 17-21

statistics, analyzing 20-32

STATS PATH command and 14-77, 14-83

timeout for 17-15

Layer 5, Expand functions at 17-10LCAN 17-15LCMP 17-14, 17-44Leased lines

advantages and disadvantages of 2-5

See also dedicated lines

LF 17-25LIFNAME attribute, ALTER LINE command and 14-14LIFNAME modifier 16-16Line buffer 17-47Line logical devices 13-1, 17-2LINEBUFSIZE attribute, INFO LINE command and 14-34LINEPRIORITY attribute



LINEPRIORITY modifier 16-17Lines

controlling 18-27

definition of 17-2


identifying down 20-35

starting 14-73

stopping 14-111

LINETF attributeALTER LINE command and 14-14


LINETF modifier 16-17, 17-23Link complete packets 17-14Link request packets 17-14LISTDEV command 18-15, 20-1, 20-4LISTENEP attribute, INFO LINE command and 14-44LNP

See Logical network partitioning

Load balancingdescription 17-32/17-34

general 19-11

multi-CPU path 19-16

Load factor balancing 17-32, 19-18, 19-19Load factor (LF) 17-25Logical devices (LDEVs), displaying 14-103Logical network partitioning (LNP)

and Expand line-handler process 8-4

configuring Expand with 8-13/8-14

planning for 3-4

Logical states 14-4Loop routing 17-28, 17-31Low pin, must set explicitly 14-10LRQ 17-14, 17-44

MManagement, network 2-8Maps exchange 17-27MAXCONNECTS attribute



MAXCONNECTS modifier 6-6


Index M

MAXRECONNECTS attributeALTER LINE command and 14-14


MAXRECONNECTS modifier 16-16/16-17, 17-52MAXTIMEOUTS attribute



MAXTIMEOUTS modifier 6-6Measure

CPU entity of 19-26


LINE entity of 19-24

monitoring performance with 20-2

NETLINE entity of 19-24

PROCESS entity of 19-25

setting measurement intervals for 19-28

SYSTEM entity of 19-23

tuning the network with 19-23

Memory dumps 20-29Mesh topology 3-14Message

43



44, INFO PROCESS $NCP command and 14-55


46




48



49



Message system, size of message 2-2, 16-15Messages

file-system 20-7

handling of 17-38/17-45

Microcode, automatic loading of 14-34Mixed topology 3-14Modem errors 14-94Modified split horizon algorithm

configuring 14-54



ModifiersSee individual modifier names

MSH 17-28Multipacket frame feature

benefits of 3-11

configuring 17-63/17-66, 19-5

considerations 17-66

PATHBLOCKBYTES modifier for 7-12, 10-13, 11-15

tuning 19-3/19-5

Multiple path table (MPT) 17-25Multi-CPU paths

automatically rebalancing 14-22

benefits and disadvantages of 3-9

configuring 17-72

congestion control and 16-26

definition 17-23

description of 2-8, 14-3, 17-2, 17-72


Index N

displaying paths in 14-51, 18-14

displaying rebalancing time for 14-56

displaying reverse pairing table (RPT) for 14-66

displaying status of 14-102

extended packet format and 16-26

guarantee message order 17-31

initiating an immediate rebalance of 14-9

load balancing for 17-72

parallel connections 8-4

performance tuning for 19-14

rebalancing 18-28, 19-16


tuning 19-14

Multi-CPU rebalance, temporary disruption in network 17-33Multi-line paths

benefits and disadvantages of 3-7, 3-9

configuring 13-1/13-22, 17-66

deriving time factors for 17-22

description of 2-8

feature 19-13

latency 19-4, 19-6

multipacket frame feature considerations for 17-66

out-of-sequence (OOS) packet buffering in 3-8

parallel connections 8-4

profiles 1-4

NNAK 17-15NAM packet size, Expand frame size and 19-12NAM process

configuring 19-11

effect on performance 19-12

Negative data packet acknowledgment packets 17-15

Neighbor nodes 17-32NETATM 17-11NETMAP

option 14-62

table 17-24

Netmap messages 17-24NETNAM protocol 17-4, 17-49Network access method (NAM) interface 17-4, 19-12Network congestion, symptoms of 20-33Network control process

configuring 6-1/6-6

message handling 17-45

See $NCP

traffic flow 17-41

Network delay 19-1Network design 20-1Network diagrams, creating 3-15Network frame size, NAM packet size and 19-12Network layer, Expand functions at 17-10Network monitoring tasks 18-13/18-19Network packet traffic, displaying 14-99Network problems 20-11/20-27Network response time 19-1Network routing table (NRT) 17-25Network status 14-98Network topology


importance of 20-1

types of 3-12/3-15

Network transparency 18-2Network tuning 19-1/19-33Network utility process 17-6NETWORKDIAMETER attribute



split horizon algorithm and 14-55

NETWORKDIAMETER modifier 6-6, 17-31


Index O

Network-related TACL commandsREMOTEPASSWORD 18-8

SYSTEM 18-3, 18-6

WHO 18-4

NEXT command 15-9NEXTSYS attribute



NEXTSYS modifier 16-18, 20-18, 20-35NODE ACK 17-14node name

character limitation 18-2

definition 18-2

NODE STAT 17-14Node status

acknowledgment 17-14

packets 17-14

NonStop TCP/IPand the line-handler process 17-5

architecture and relationship to Expand 8-2

overview 17-53

selecting as environment 1-10, 1-11

troubleshooting 20-16

NonStop TCP/IP processassociating the line-handler with 1-10, 1-11, 8-9/8-10

determining the preferred and alternate processes for WAN 1-8

overview 17-53

relationship to Expand 8-2

NonStop TCP/IPv6and configuring Expand for IPv6 communications 1-11

co-locating the TCP6SAM process and line-handler 19-11

determining the preferred and alternate processes for WAN 1-8

memory constraints 17-48

overview 17-53

selecting as environment 1-10, 1-11

Non-neighbor nodes 17-31NRT 17-25

OOBEYFORM option


INFO LINE Command 14-45

INFO PATH Command 14-30

INFO Process Command 14-64

OCTAL command 15-10OLDLINESET option 14-61OLDNETMAP option 14-64OSI Layers

See individual layers

OSI Reference Model 17-9OSSPACE attribute



OSSPACE modifier 16-18OSTIMEOUT attribute



OSTIMEOUT modifier 16-18, 17-71, 19-10OUT command 15-11Out-of-sequence buffer



Out-of-sequence packets, handling of 17-43

PPacket format 19-9Packet size

changing 19-28

Expand subsystem overhead and 19-8

Packetsdisplaying traffic 14-99

incoming 14-98

per message 19-13

synchronization of 17-16


Index P

Packet-switched data networks 2-5, 3-2Pair count balancing 17-32, 19-18/19-19partially qualified file name 18-2Passive connect requests 17-52, 17-55, 17-60Passthrough traffic


handling of 17-41, 17-45

measuring 19-28, 19-31

reducing 19-31

routing 2-7

Passwordsglobal 18-10

remote 2-11, 18-8/18-9

Path change status packet 17-15Path change status response packet 17-15Path logical device 13-1, 17-2PATHBLOCKBYTES attribute



PATHBLOCKBYTES modifier 7-12, 10-13, 11-15, 16-19, 17-66, 19-5Pathchange messages 17-24PATHPACKETBYTES attribute



PATHPACKETBYTES modifier 7-12, 8-33, 9-18, 10-13, 11-15, 16-19, 16-20, 17-67, 19-6, 19-9Paths

aborting 14-8, 14-101

changing attributes for 14-11

controlling 18-27

definition of 17-2

determining LDEV for 14-103

determining state of 14-101

determining status of 14-51, 14-103

determining time factor (TF) for 14-63

displaying information about 18-18, 20-32

identifying down 20-34

identifying lines in 14-60

measuring hops in 14-63

multi-line 19-4, 19-6, 19-13

starting 14-73

stopping 14-8, 14-101

PATHSET option 14-51, 14-65PATHTF attribute, INFO PATH command and 14-26PATHTF modifier 16-20, 17-23PCHG CMD 17-15PCHG RSP 17-15Performance tuning 2-8, 19-1/19-33Permanent virtual circuits (PVCs) 9-5, 17-58PEXPMATM profile 5-3, 13-5PEXPMIP profile 5-3, 13-5, 13-9, 13-21, 13-22PEXPMNAM profile 5-3, 13-5, 13-9, 13-20PEXPMSAT profile 5-3, 13-5, 13-9, 13-18PEXPMSWN profile 5-3, 13-5, 13-9, 13-18PEXPNCP profile 5-3, 6-1, 6-4PEXPPATH profile 1-4, 5-3, 13-3, 13-4, 13-16PEXPSATM profile 5-3, 9-19PEXPSIP profile 5-3, 8-34PEXPSNAM profile 5-3, 10-14, 11-16PEXPSSAT profile 5-3, 7-12PEXPSSN profile 1-4, 5-3, 12-8, 12-13PEXPSSWN profile 5-3, 7-12PEXQMATM profile 1-5PEXQMIP profile 1-5PEXQMNAM profile 1-5PEXQMSAT profile 1-5PEXQMSWN profile 1-5PEXQSATM profile 1-4PEXQSIP profile 1-4, 8-22PEXQSNAM profile 1-4PEXQSSAT profile 1-4PEXQSSN profile 1-4PEXQSSWN profile 1-4Physical Layer, Expand functions at 17-11PING 14-78, 14-83, 17-16, 17-25


Index Q

Pool failures 20-12PORT modifier 20-18Port numbers 8-17/8-18, 8-20, 17-54PRIMARY PROCESS command 14-70, 18-28Prioritization, message 17-40Priority routing 2-8, 17-40PROBE PROCESS command 20-5PROBE PROCESS $NCP command 14-71/14-73, 18-13, 20-10, 20-12, 20-31Processes

accessing remote 18-9

location of 19-11

Processor overhead 19-13Processor type, effect on performance of 19-11Profiles

changing 18-21

creating 5-3

displaying modifiers in 18-15

line logical device 13-5

path logical device 13-4

relation of subtypes to 5-3

See also individual profile file names

PROGRAM attributeALTER LINE command and 14-14


PROGRAM file 20-17PROGRAM modifier 16-20Programmatic network access 2-2PROTOCOL modifier 20-18Protocols

End-to-End 17-13

HDLC Extended Mode 2-5, 3-2, 17-11

HDLC Normal 2-5, 17-11

NETATM 17-11

NETNAM 17-4

satellite-efficient 2-5

switched-line facilities 2-5

voice-grade leased line 2-5

X.25 2-5

PSS 3-2PTrace commands 15-5/15-13PVC connections 9-1, 17-58PVCNAME attribute



PVCNAME modifier 16-21PVCs 9-5, 17-58

QQIO

configuring 17-48

Kseg2 memory segment 17-48

memory space 17-48

subsystem 8-3, 9-2, 10-3, 17-5, 17-48, 17-53, 17-58, 20-22, 20-27

QIO Monitor process (QIOMON) 17-54, 17-59, 20-2QUALITYTHRESHOLD attribute



QUALITYTHRESHOLD modifier 16-21QUALITYTIMER attribute



QUALITYTIMER modifier 16-21

RREADBUFFERS attribute, INFO LINE command and 14-34Rebalancing

algorithm 3-10, 17-32

multi-CPU paths 18-28, 19-16

Reconfigurationnetwork 18-20

online 2-10

RECORD command 15-11


Index S

Remote passwords 2-11, 17-44, 18-8Remote processes 18-9Remote programs, running 18-6REMOTEPASSWORD command 2-11, 18-8, 18-10Reply packets 17-44Request packets 17-44Resource use 19-1Response time, slow 20-31, 20-33Retries, Layer 4 14-25, 17-15RETRYPROBE attribute

ALTER LINE command and 14-14, 14-16



RETRYPROBE modifier 16-21Reverse pairing table (RPT)


displaying 14-66

Route, definition of 17-27Routing

determining best-path route 20-33


Routing behavior 17-23Routing, description of 17-22/17-31RPT

See reverse pairing table (RPT)

RPT option 14-66RSIZE attribute


RSIZE modifier 16-22, 17-23RUN command 18-6RXWINDOW attribute



RXWINDOW modifier 16-22, 17-52

SSABM frames 20-35

Safeguard security systemdescription of 2-11

functions at OSI Layer 5 17-10

managing 18-12

role in security processing 17-44

Satellite connections, benefits and disadvantages of 3-2Satellite-connect line-handler process



SCF commandsSee individual command names

SCP 20-16Security

additional techniques 18-12

network 2-11

processing 17-39, 17-44

SELECT command 15-12Selective reject feature 3-2Selector byte 9-6, 17-59Send window 17-21Sensitive commands 14-6ServerNet cluster

coexistence with ATM or IP 4-3/4-5

configuration considerations 4-2

connected to external node 4-1/4-7

monitor process

description 12-4

Layer 2 functions of 17-11, 17-49

topology examples 4-1/4-7

ServerNet LAN Systems Access (SLSA) subsystem 7-3, 9-1, 11-4ServerNet Wide Area Network (SWAN) concentrator 7-4, 10-4Session Layer, Expand functions at 17-10SH algorithm 14-54, 17-30Single-line path 17-22SLSA subsystem 7-3, 11-4SNA connections


multiline path with 3-3


Index S

SNAX/APN line-handler processLayer 2 functions of 17-49

SNAX/APN process 11-3, 17-4SNMPCODE file 20-17SPEED attribute



SPEED modifier 16-23, 17-23SPEEDK attribute



SPEEDK modifier 16-23, 17-23Split-star topology 3-13SPRINTNET 3-2SRCIPADDR attribute



SRCIPADDR modifier 16-25SRCIPPORT attribute



SRCIPPORT modifier 16-25SSNPRF profile 12-13Stack space 17-47Star topology 3-13START command 14-73/14-74START DEVICE command 18-26START LINE command 18-27START PATH command 18-27START ROUTE command 20-17STARTUP attribute, INFO LINE command and 14-33, 14-39, 14-43, 14-48STARTUP_OFF modifier 16-25STARTUP_ON modifier 16-25States, definition of 14-4Statistics

analyzing Layer 2 20-32

analyzing Layer 4 20-32

STATS LINE command 14-74/14-95, 18-17, 20-1, 20-5, 20-32STATS PATH command 14-74/14-80, 18-18, 20-1, 20-5STATS PATH NODE command 14-81/14-85STATS PROCESS command 14-97/14-100STATS PROCESS $NCP command 18-13/18-14STATUS command 14-101STATUS DEVICE command 18-15STATUS LINE command 14-103/14-110, 18-17/18-18, 20-5STATUS PATH command 14-101/14-103, 18-18, 20-5STOP command 14-111STOP DEVICE command 18-26STOP LINE command 18-27STOP PATH command 18-27Subdevices 17-51SUBNETMASK attribute 20-17Subnetworks 18-11Subsystem components, Expand 17-2Subsystem Control Point (SCP) 20-16Subtypes

direct-connect line-handler process 7-9

Expand 18-16

Expand-over-ATM line-handler process 9-14

Expand-over-IP line-handler process 8-24

Expand-over-SNA line-handler process 11-12

Expand-over-X.25 line-handler process 10-10

line logical device 13-9

network control process 6-3

path logical device 13-6

relation of profiles to 5-3

satellite-connect line-handler process 7-9

Subvolume name 18-2


Index T

Super ID user 18-11SUPERPATH attribute



STATUS PATH command and 14-102

SUPERPATH option 14-67Superpath rebalance 14-68, 19-19Superpaths feature 19-17SUPERPATH_OFF modifier 16-25SUPERPATH_ON modifier 7-12, 10-13, 11-15, 16-25Supervisory frames, STATS LINE command and 14-92SVC connections 9-1, 17-59SVCs 9-5, 17-58SWAN concentrator 7-3/7-4, 10-3/10-4, 11-4SWAN concentrator, resolving problems with 20-13/20-15Switched virtual circuits (SVCs) 9-5, 17-58Synchronization of packets 17-16SYSTEM command 18-3, 18-6System load, performing 18-25System name

changing 18-23

viewing 18-24

System numberchanging 18-23

duplicate 20-36

viewing 18-24

SYSTEMS option 14-51, 14-68

TT1 facilities 3-1, 17-3TACL commands

CPUS 20-11

network-related 18-2

REMOTEPASSWORD 18-8

RUN 18-6

SYSTEM 18-3, 18-6

WHO 18-4

TCP6SAM processassociating the line-handler with 1-10, 1-11, 8-11/8-14, 8-15

determining the preferred and alternate for WAN 1-8

modifier for 8-25

overview 17-53

TCPSAM processdetermining the preferred and alternate for WAN 1-8

overview 17-53

TCP/IPSee NonStop TCP/IP and NonStop TCP/IPv6 1-8

TCP/IPv6See NonStop TCP/IPv6

Temporary discontinuity 17-28TFTP server processes 20-16THRESHOLD attribute, INFO LINE command and 14-35Throughput 19-1Time factor (TF)

displaying 14-63, 18-14

path 17-22

route 17-27

Time factors, order of selection 17-23TIMEFACTOR attribute



Timeoutslevel 2 17-66

level 4 17-15

out-of-sequence (OOS) 17-18, 17-71

TIMERBIND attributeALTER LINE command and 14-16



TIMERINACTIVITY attributeALTER LINE command and 14-15, 14-17


Index U



TIMERINACTIVITY modifier 16-26TIMERPROBE attribute




TIMERPROBE modifier 16-26TIMERRECONNECT attribute




TIMERRECONNECT modifier 16-27Topology, effect on performance of 19-20TRACE command 14-112/14-117TRACE LINE command 18-19TRACE PATH command 18-19TRACE PROCESS $NCP command 18-19Trace request packets 17-16Tracing 18-19Traffic pattern 19-15Traffic patterns, multi-CPU paths and 19-15Transmission Control Protocol (TCP) 17-5, 17-53Transmission Group 1 (T1) facilities 3-1, 17-3TRANSPAC 3-2Transparency, network 2-1Transport Layer, Expand functions at 17-10Tree topology 3-14Trivial File Transfer Protocol (TFTP) server processes 20-16Tri-star topology 3-14Troubleshooting 2-8, 20-1/20-36Tuning 2-8, 19-1/19-33TXWINDOW attribute



TXWINDOW modifier 16-27, 17-52, 19-6, 19-10TYMNET 3-2TYPE modifier 20-18Types, object 14-2

UUDP port 8-17/8-19, 8-20Unnumbered frames, STATS LINE command and 14-92User complaints 20-4User Datagram Protocol (UDP) 17-5, 17-53User ID 2-11User IDs, global 18-7USERID file 17-44

VV6DESTIPADDR attribute



V6DESTIPADDR modifier 16-28V6DESTIPADDR parameter 1-11V6SRCIPADDR attribute



V6SRCIPADDR modifier 16-29V6SRCIPADDR parameter 1-11Variable packet size 19-14Variable packet size feature

benefits of 3-11


PATHPACKETBYTES modifier for 7-12, 10-13, 11-15

Variable packet-size 19-5VERSION command 14-117VERSION PROCESS command 18-15VERSION PROCESS $NCP command 18-13VOLUME command 18-3


Index W

Volume name 18-2

WWAN shared driver 7-3, 11-3WAN subsystem

description of 5-4

manager process 20-15

resolving problems with 20-15/20-17

WANBoot processes 20-16WHO command 18-4Window size 19-14

XX25AM line-handler process, layer 2 functions of 17-49X25AM process 10-3, 17-4, 20-18X.25 Access Method (X25AM) 2-5X.25 connections


general description of 2-5

multiline path with 3-3

Special Characters$NCP

changing modifiers for 18-20

configuration considerations 4-1

definition of 17-6



$ZEXP 17-7$ZNET 20-16$ZNUP 17-6$ZZSCL 12-4, 17-11, 17-49$ZZWAN 20-15


Index Special Characters


expand configuration and management manual (h06.21+, j06.10+)h20628. · expand configuration and...

Documents