Download IP CIP compared to other NonStop TCP/IP products – Technical

Technical white paper
IP CIP compared to other
NonStop TCP/IP products
Table of contents
Introduction .................................................................................................................................................................................... 2
Comparison of NonStop TCP/IP Products ................................................................................................................................ 2
Subsystem identity ....................................................................................................................................................................... 3
Platforms .................................................................................................................................................................................... 4
CLIMs vs. adapters......................................................................................................................................................................... 4
Network partitioning differences ............................................................................................................................................... 4
MULTIPROV compatibility and migration ................................................................................................................................. 5
Limitations and restrictions when using MULTIPROV in CIP ................................................................................................ 5
Failover differences ...................................................................................................................................................................... 7
SAM process differences ......................................................................................................................................................... 8
Linux differences ........................................................................................................................................................................... 9
Related documentation ............................................................................................................................................................... 9
Conclusion ..................................................................................................................................................................................... 10
For more information ................................................................................................................................................................. 10
Click here to verify the latest version of this document
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Introduction
This paper compares the IP CIP (Cluster I/O Protocols) product to previous TCP/IP products for NonStop systems. CIP is the
new product introduced to support IP CLIMs. A summary of the relative strengths and weaknesses of each product is shown
at the end.
The following table gives an overview of the differences between all the NonStop TCP/IP products including CIP.
Comparison of NonStop TCP/IP Products
Conventional TCP/IP
Parallel TCP/IP 1
NonStop TCP/IPv6
CIP
Subsystem name
TCP/IP
PTCP/IP
TCP/IPv6
CIP
Platform
• S-series
• S-series
Interface types
• S-series
• NS-series
• NS-series
• NS-series
• BladeSystem
• BladeSystem
• BladeSystem
• 10M/100M/1GbE
• 10M/100M/1GbE
• 10M/100M/1GbE
• 10M/100M/1GbE
• InfiniBand
• ATM
• SNAP (Token Ring
or Ethernet)
• X.25
Jumbo frames
No
Yes
Yes
Yes
Adapters
• MFIOB
• MFIOB
• MFIOB
• CLIM
• IOMF2+E4SA
• IOMF2+E4SA
• IOMF2+E4SA
• IOMF2+FESA
• IOMF2+FESA
• IOMF2+FESA
• IOMF2+GESA
• IOMF2+GESA
• IOMF2+GESA
• IOAM+G4SA
• IOAM+G4SA
• IOAM+G4SA
• VIO+G4SA
• VIO+G4SA
• IOMF2+ATM3SA
• IOMF2+TRSA
2
Maximum adapters
4 per process pair
60
60
48
Maximum HW
interfaces
4 per process pair
240
240
240
IP versions
IPv4
IPv4
IPv4, IPv6
IPv4, IPv6
SCTP
No
No
No
Yes
Protocol stack
ancestry
BSD4.3
BSDi4.4
BSD/DEC
Linux
Protocol stack
location
One NonStop process
pair
One per NonStop
system processor
One per NonStop
system processor
Offloaded to CLIM
Remote sockets
Yes
No
No
No
Fault-tolerant
sockets 2
Yes
No
No
No
Round-robin
listeners
Not supported
Maximum one per
processor per port
Maximum one per
processor per port
No limit per
processor per port
Network
partitioning
Yes
No
Yes
Yes
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Conventional TCP/IP
Parallel TCP/IP
NonStop TCP/IPv6
CIP
Minimum partition
size
Interface
N/A
Interface
Interface
Interface failover 3
None
Full
Full
Partial
IPSec
No
No
No
Yes
Automatic DNS
updates
No
No
For IPv6
No
Configuration
commands
• TCP/IP via SCF
• $ZZTCP via SCF
• $ZZTCP via SCF
• $ZZCIP via SCF
• $ZZLAN via SCF
• $ZZLAN via SCF
• $ZZLAN via SCF
• TCPSAM via SCF
• TCP6SAM via SCF
• climconfig via
CLIMCMD
• CIPSAM via SCF
1
Parallel TCP/IP is no longer available for sale.
Fault-tolerant sockets transfer a socket from an application in one processor to its backup in another. Only conventional TCP/IP supports them.
3
Interface failover transfers sockets from one interface to another. Both TCP/IPv6 and CIP support this feature, but CIP failover from one CLIM to another does
not include TCP and SCTP connections.
2
Subsystem identity
The CIP subsystem has its own identification, program names, process names, and version numbers different from other
subsystems.
Conventional TCP/IP
Parallel TCP/IP
NonStop TCP/IPv6
CIP
Subsystem name
TCP/IP
PTCP/IP
TCP/IPv6
CIP
SPI subsystem ID
ZTCI
ZTCP
ZTC6
ZCIP
SPI subsystem
number
80
220
246
259
Transport provider
program name
TCP/IP
TCPSAM
TCP6SAM
CIPSAM
Management
program name
TCP/IP
TCPMAN
TCP6MAN
CIPMAN
Management
process name
Same as transport
provider
$ZZTCP
$ZZTCP
$ZZCIP
Monitor program
name
N/A
TCPMON
TCP6MON
CIPMON
Monitor process
name
N/A
$ZPTMx
$ZPTMx
$ZCMnn
If your application expects its TCP/IP transport provider to have certain names, IDs, or versions, you will need to change it to
run with CIP.
3
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Platforms
CIP is supported only on NS-series and NonStop BladeSystem. Support on S-series is not planned.
Conventional TCP/IP features
Conventional TCP/IP supports the following features that no other NonStop TCP/IP product supports:
• TCP/IP over ATM, Token Ring, or X.25
• Remote sockets—Socket requests from remote NonStop systems via Expand
• Fault-tolerant sockets—Transferring a socket from an application in one processor to its backup in another
Applications that really need any of these features must continue to use conventional TCP/IP.
CLIMs vs. adapters
Unlike previous TCP/IP products, CIP does not use the SLSA subsystem, so does not support the plethora of adapters
that SLSA manages. CIP uses a CLIM instead, which has higher speed and functionality than any of the SLSA-supported
Ethernet adapters.
E4SA
FESA
GESA
G4SA
CLIM
Number of HW
interfaces
4
1
1
4
5
HW interface
speeds
10 Mb
10/100 Mb
2–10/100/1000 Mb
5–10/100/1000 Mb
HW interface
media
4-Copper
10/100/1000 Mb
2–10/100 Mb
1-Copper
1-Copper
4-Copper or
5-Copper or
2-Copper, 2-Fiber
3-Copper, 2-Fiber
or
3-Copper, 2-IB
Jumbo frames
No
Yes
Yes
Yes
Yes
Onboard
processing
Filters
Filters
Filters
Filters
Full protocol stack
Maximum
connections
5000
5000 per
adapter
25000 per
adapter
80000 per 1000 Mb
64000 per CLIM
per HW
interface
HW interface
25000 per 100 Mb
HW interface
Previous TCP/IP products also support the MFIOB, which is usually used for access to the dedicated service LAN. In addition
to the five ports listed above, each CLIM has a separate port that is used for the dedicated service LAN.
Network partitioning differences
Each conventional TCP/IP process is a separate protocol stack, so you are not limited to connecting a NonStop system to
just one network, but can run multiple TCP/IP processes and then connect the system to multiple independent networks,
where the hosts on each network have routes to all other hosts in the network, but there are no routes between the
networks. Each process connects to a separate network and is separately configured. The routing table and scope of socket
operations are restricted to an individual network. You may have had to configure multiple TCP/IP processes for a single
network to meet throughput or other requirements. Each such process still runs independently, so cannot take full
advantage of the connectivity in the network. Sometimes, this is what you want; it can confine applications to certain
interfaces or routing tables. Usually, however, using the full network connectivity would give you advantages in both fault
tolerance and bandwidth as you create more options to shorten network routes and route around failures.
Both TCP/IPv6 and CIP are system-wide subsystems and allow many more interfaces, so there is no need to split single
network connectivity because of throughput concerns. If you are connected to multiple independent networks or need to
confine applications, you can create partitions that act like separate protocol stacks. The partitions are called LNPs in
TCP/IPv6 and Providers in CIP (see figure 1). Applications on one partition are isolated from applications on different
partitions on the same system in the same way they would be if using different conventional TCP/IP processes.
Communication between such applications will only be through the attached LANs. TCP/IPv6 does not forward packets
4
Technical white paper | IP CIP compared to other NonStop TCP/IP products
internally between partitions. CIP initially did not allow network partitions to be formed with the same granularity as that of
TCP/IPv6. Multiple CLIMs could belong to the same provider, but it did not allow two interfaces in a CLIM to be in different
providers. With the introduction of Multiple Provider per CLIM (MULTIPROV) feature in the newer CIP software versions, it is
possible to configure multiple providers in a single CLIM. In other words, it does allow assigning individual interfaces on the
same CLIM to different partitions.
CIP MULTIPROV has a benefit over TCP/IPV6 LNP in a way that there exists a loopback provider, when a provider is added in
MULTIPROV a “lo” interface gets automatically added. This is not the case in TCP/IPV6, it is not possible to create an LNP
with just a loopback; you have to add at least one non-loopback SUBNET.
MULTIPROV compatibility and migration
There are two different modes in which data provider namespaces are maintained: A mode where multiple providers are
supported (MULTIPROV ON) and a “compatibility mode” where the CLIM operates as it did previously with only a single
provider configured (MULTIPROV OFF). The mode is configured by the user with a new SCF ALTER CLIM, MULTIPROV ON
command, which is ultimately recorded on both the CLIM object in the host, as well as on the CLIM. With MULTIPROV ON,
climconfig configuration objects (including interfaces, PSKs, SPs, SAs, Remotes, and VPNs) are explicitly associated with a
provider name, corresponding to the name of the provider record in SCF.
Prior to the introduction of MULTIPROV support, there was only a single data provider—and all CLIM configuration objects
were associated with that provider. In order to provide compatibility with this configuration model, the CLIM allows
“compatibility” mode in which there is a single data namespace and the provider is not named. All CLIMs are shipped from
manufacturing with MULTIPROV features disabled (MULTIPROV OFF), and older CLIMs updated with the MULTIPROV-aware
version of the CIP software are similarly set to MULTIPROV OFF. CLIMs with MULTIPROV ON do not allow climconfig objects
to be configured without specifying a provider name. CLIMs with MULTIPROV OFF do not allow a provider name to be
specified, and objects are implicitly assigned to the single data namespace.
Limitations and restrictions when using MULTIPROV in CIP
• A single interface cannot be shared by multiple providers.
• A maximum of 7 providers can be configured in a CLIM.
• When there are multiple providers configured on a CLIM (other than default provider) while MULTIPROV is ON, to convert
that CLIM to MULTIPROV OFF all the associated interfaces in the non-default providers have to be deleted and reassigned
to default provider and only then it needs to be converted to MULTIPROV OFF.
5
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Figure 1. Network partitioning is supported by three products, but its architecture and terminology is different in each.
6
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Failover differences
Parallel TCP/IP and TCP/IPv6 both support a form of failover where an adapter failure, interface failure, or disconnection of
an interface from the network can cause the resources of the affected interfaces, such as IP addresses, routes, sockets, and
connections to be migrated to other interfaces with no application awareness. CIP supports a similar feature, but because
the protocol state is kept in the CLIMs, it cannot preserve TCP and SCTP connections when it migrates interface resources
from one CLIM to another. It, therefore, provides two types of interface failover (see figure 2).
Multiple physical interfaces on a CLIM can be combined using a bonding interface so they share resources. If one of the
interfaces fails or is disconnected from the network, the other interfaces under the same bonding interface takes over with
no loss of connections and no application awareness.
In case an entire CLIM fails, CIP also supports CLIM-to-CLIM failover. It can migrate IP addresses, routes, tunnels, multicast
groups, and sockets on affected interfaces to other CLIMs, but not TCP or SCTP connections. On the system experiencing
failover, sockets with connections get an ECONNRESET error on the current or next socket operation. The application is
expected to close the socket. CIP attempts to send a reset indication to the remote end of TCP connections so the remote
application also gets an ECONNRESET error, but the TCP/IP protocol does not allow for acknowledgement of resets, so CIP
cannot guarantee delivery.
The socket used by a server application to accept incoming TCP or SCTP connections does not itself have a connection, so
the application is unaware when it fails over, but it does get an ECONNRESET error for each of the connections it previously
accepted. A client application gets an ECONNRESET error during failover, whether the failure occurred locally or on the
server system, and should close the socket, then get a new socket and try to reestablish the connection.
Figure 2. CLIMs added for both types of failover: Boxed interfaces are combined into a bonding interface and two CLIMs are assigned to
each network for CLIM-to-CLIM failover. An interface to each network can fail with no application awareness. A CLIM failure results in
connection loss, but quick transfer of network resources to the other CLIM.
7
Technical white paper | IP CIP compared to other NonStop TCP/IP products
SAM process differences
All the NonStop TCP/IP products released after conventional TCP/IP provide a SAM process with an SCF interface that
supports a compatible subset of the conventional TCP/IP SCF commands. The SAM commands allow you to monitor the
TCP/IP stack, but you must make configuration changes through the management process. CIPSAM, the SAM process for
CIP, continues this tradition, but because the TCP/IP stack is on the CLIM and not available to CIPSAM, some of the
monitoring commands must use the management process or CLIMCMD. The following table shows for each NonStop TCP/IP
product the conventional TCP/IP SCF commands that must be directed to a process other than the SAM process.
Conventional TCPIP
command
Parallel TCP/IP
NonStop TCP/IPv6
CIP
ABORT ROUTE
$ZZTCP
$ZZTCP
(N/A) 4
ABORT SUBNET
$ZZTCP
$ZZTCP
CLIMCMD ifstop
ADD ENTRY
$ZZTCP
$ZZTCP
CLIMCMD climconfig
ADD ROUTE
$ZZTCP
$ZZTCP
CLIMCMD climconfig
ADD SUBNET
$ZZTCP
$ZZTCP
CLIMCMD climconfig
ALTER SUBNET
$ZZTCP
$ZZTCP
CLIMCMD climconfig
DELETE ENTRY
$ZZTCP
$ZZTCP
CLIMCMD climconfig
DELETE ROUTE
$ZZTCP
$ZZTCP
CLIMCMD climconfig
DELETE SUBNET
$ZZTCP
$ZZTCP
CLIMCMD climconfig
INFO ENTRY
$ZZTCP
$ZZTCP
CLIMCMD climconfig
INFO ROUTE
TCPSAM
TCP6SAM
CLIMCMD climconfig
LISTOPENS PROCESS
TCPSAM
TCP6SAM
$ZZCIP or CLIMCMD netstat
NAMES ENTRY
$ZZTCP
$ZZTCP
CLIMCMD climconfig
NAMES ROUTE
TCPSAM
TCP6SAM
CLIMCMD climconfig
START ROUTE
$ZZTCP
$ZZTCP
(N/A)
START SUBNET
$ZZTCP
$ZZTCP
CLIMCMD ifstart
STATS PROCESS
TCPSAM
TCP6SAM
CLIMCMD netstat
STATS ROUTE
TCPSAM
TCP6SAM
CLIMCMD route
STATS SUBNET
TCPSAM
TCP6SAM
CLIMCMD netstat
STATUS ENTRY
$ZZTCP
$ZZTCP
CLIMCMD arp
STATUS PROCESS
TCPSAM
TCP6SAM
$ZZCIP
STATUS ROUTE
TCPSAM
TCP6SAM
$ZZCIP or CLIMCMD climconfig
STOP ROUTE
$ZZTCP
$ZZTCP
(N/A)
STOP SUBNET
$ZZTCP
$ZZTCP
CLIMCMD ifstop
TRACE SUBNET
TCPSAM
TCP6SAM
CLIMCMD tcpdump
4
8
Target process for equivalent command
CIP routes are always in a started state, so there are no commands to change or display the state.
Technical white paper | IP CIP compared to other NonStop TCP/IP products
Linux differences
The previous NonStop TCP/IP products were all derived from the BSD implementation of TCP/IP, but CIP uses the Linux
implementation, which is different in many small ways. CIP tries to be as compatible as possible with previous NonStop
products, but some differences remain. Following is a list of the most prominent:
• When selecting a send interface, Linux considers only configured interfaces, but does not check for link pulse (a working
network connection).
• Linux may send over an interface other than the one associated with the bind address if it has a route and is in the same
subnet.
• Linux does not allow a bind to INADDR_ANY and a specific address on the same port.
• Linux supports most but not all the same setsockopt options.
The CIP manual [1] contains a more complete list.
Related documentation
1.
2.
HP NonStop Cluster I/O Protocols (CIP) Configuration and Management Manual.
HP NonStop TCP/IPv6 Configuration and Management Manual.
Relative Product Strengths and Weaknesses
Strengths
Conventional TCP/IP
Parallel TCP/IP
NonStop TCP/IPv6
CIP
• All platforms
• Scalable
architecture
• Scalable
architecture
• Scalable
architecture
• Seamless interface
failover
• All platforms
• Offloaded
protocol stack
• ATM, Token Ring,
and X.25 interfaces
• Remote sockets
• IPv6 support
• Seamless interface
failover
• Fault-tolerant
sockets
• IPv6 support
• SCTP support
• IPSec support
• Partial interface
failover
• Faster tracking
of industry
standard
changes
Weaknesses
• No jumbo frames
• S-series only
• Process bottleneck
• No network
partitioning
• No round-robin
filtering
• No interface
failover
• No tracking of
industry standard
changes
• Slow tracking of
industry standard
changes
• NS-series and
BladeSystem
only
• No connection
failover across
CLIMs
• No tracking of
industry standard
changes
9
Conclusion
The IP CLIM offers a new approach to providing TCP (and SCTP) protocol support on NonStop systems. With this new
approach, there is a need to cover many technical ramifications that this white paper delves into. With the history of TCP on
NonStop systems over the years, it can become challenging to keep the different products and their features straight. This
white paper lays out the differences and provides guidance on using the products in your environment.
For more information
For the NonStop Networking overview (explains the IP CLIM and other NonStop networking products), visit
hp.com/go/nonstop-docs.
For the planning guide (contains high-level information about the IP CLIM), visit hp.com/go/nonstop-support-docs (internal).
For the Cluster I/O Protocols (CIP) configuration and management manual (contains detailed configuration information
about the CIP subsystem, which supports the IP CLIM), visit hp.com/go/nonstop-docs.
For the HP NonStop TCP/IPv6 configuration and management manual (contains detailed configuration information about
the TCP/IPv6 subsystem), visit hp.com/go/nonstop-docs.
To know more about HP NonStop products, visit hp.com/go/nonstop.
Sign up for updates
hp.com/go/getupdated
Rate this document
© Copyright 2009–2011, 2013 Hewlett-Packard Development Company, L.P. 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.
4AA2-3690ENW, January 2013