Read IP CIP compared to other HP NonStop TCP/IP products (US English) text version

IP CIP compared to other HP NonStop TCP/IP products

Technical white paper Table of contents

Management summary ......................................................................................................................... 2 Comparison of NonStop TCP/IP products ............................................................................................... 2 Subsystem identity ............................................................................................................................... 3 Platforms............................................................................................................................................. 3 Conventional TCP/IP features ................................................................................................................ 4 CLIMs vs. adapters .............................................................................................................................. 4 Network partitioning differences ............................................................................................................ 5 Failover differences .............................................................................................................................. 9 SAM process differences .................................................................................................................... 11 Linux differences ................................................................................................................................ 12 Relative product strengths and weaknesses ........................................................................................... 12 Conclusion ........................................................................................................................................ 12 References ........................................................................................................................................ 13

Management summary

This paper compares the IP Cluster I/O Protocols (CIP) product to previous TCP/IP products for HP NonStop systems. CIP is the new product introduced to support IP Cluster I/O Modules (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 Subsystem name Platform TCPIP

· S-series · NS-series · BladeSystem

Parallel TCP/IP 1 PTCPIP

· S-series

NonStop TCP/IPv6 TCPIPv6

· S-series · NS-series · BladeSystem

Cluster I/O Protocols CIP

· NS16x00 · BladeSystem · NS5000CG/T · 10M/100M/1G

Interface types

· 10M/100M/1G

Ethernet

· 10M/100M/1G

Ethernet

· 10M/100M/1G

Ethernet

Ethernet

· ATM · SNAP (Token Ring

or Ethernet)

· X.25

Jumbo frames Adapters

No

· MFIOB · IOMF2+E4SA · IOMF2+FESA · IOMF2+GESA · IOAM+G4SA · VIO+G4SA · IOMF2+ATM3SA · IOMF2+TRSA

Yes

· MFIOB · IOMF2+E4SA · IOMF2+FESA · IOMF2+GESA · IOAM+G4SA

Yes

· MFIOB · IOMF2+E4SA · IOMF2+FESA · IOMF2+GESA · IOAM+G4SA · VIO+G4SA

Yes

· CLIM

Maximum adapters Maximum HW interfaces IP versions SCTP Protocol stack ancestry Protocol stack location Remote sockets Fault-tolerant sockets 2 Round-robin listeners

4 per process pair 4 per process pair IPv4 No BSD4.3 One NonStop process pair Yes Yes Not supported

60 240 IPv4 No BSDi4.4 One per NonStop system processor No No Maximum one per processor per port

60 240 IPv4, IPv6 No BSD/DEC One per NonStop system processor No No Maximum one per processor per port

48 240 IPv4, IPv6 Yes Linux Offloaded to CLIM No No No limit per processor per port

1 2

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.

2

Conventional TCP/IP Network partitioning Minimum partition size Interface failover 3 IPSec Automatic DNS updates Configuration commands Yes Interface None No No

· TCPIP through SCF · $ZZLAN

Parallel TCP/IP No N/A Full No No

· $ZZTCP

NonStop TCP/IPv6 Yes Interface Full No For IPv6

· $ZZTCP through

Cluster I/O Protocols Yes CLIM Partial Yes No

· $ZZCIP through SCF · Climconfig through

through SCF through SCF through SCF

SCF

through SCF

· $ZZLAN

· $ZZLAN

through SCF through SCF

CLIMCMD

· TCPSAM

· TCP6SAM

· CIPSAM through SCF

Subsystem identity

The CIP subsystem of course has its own identification, program names, process names, and version numbers that are different from other subsystems.

Conventional TCP/IP Subsystem name SPI subsystem ID SPI subsystem number Transport provider program name Management program name Management process name Monitor program name Monitor process name TCPIP ZTCI 80 TCPIP TCPIP Same as transport provider N/A N/A Parallel TCP/IP PTCPIP ZTCP 220 TCPSAM TCPMAN $ZZTCP TCPMON $ZPTMx NonStop TCP/IPv6 TCPIPv6 ZTC6 246 TCP6SAM TCP6MAN $ZZTCP TCP6MON $ZPTMx Cluster I/O Protocols CIP ZCIP 259 CIPSAM CIPMAN $ZZCIP CIPMON $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.

Platforms

CIP is currently supported on NonStop BladeSystem, NS16x00, NS5000CG/T, and NS2000 systems. Support on S-series is not planned.

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.

3

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 through 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 Number of HW interfaces HW interface speeds (megabits per second) HW interface media Jumbo frames Onboard processing Maximum connections 4 FESA 1 GESA 1 G4SA 4 Two 10/100/1000 Two 10/100 4- Copper or 2- Copper, 2- Fiber Yes Filters 80,000 per 1000 Mb interface; 25,000 per 100 Mb interface CLIM 5

10

10/100

10/100/1000

Five 10/100/1000 5- Copper or 3- Copper, 2- Fiber Yes Full protocol stack

4- Copper No Filters 5,000 per HW interface

1- Copper Yes Filters 5,000 per adapter

1- Copper Yes Filters 25,000 per adapter

64,000 per CLIM

Previous TCP/IP products also support the MFIOB, which is usually used for access to the dedicated service LAN. In addition to the preceding five ports listed, each CLIM has a separate port that is used for the dedicated service LAN.

4

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). The main difference is that TCP/IPv6 can assign individual interfaces to a partition whereas CIP assigns whole CLIMs, each of which is a group of five interfaces. This is because the Linux TCP/IP stack on the CLIM has no partitioning capability of its own.

Figure 1: Network partitioning

Network partitioning is supported by three products, but its architecture and terminology is different in each.

If you do not use partitions or you have a large number of interfaces in each partition, this difference poses no problem when configuring CIP, but you may have a Conventional TCP/IP or TCP/IPv6 configuration that has a large number of partitions, each with only one or two interfaces. It may at first appear that CIP would require a separate CLIM for each partition, but this is not always true. There are various ways around this apparent requirement, depending on the reason you are using such fine-grained partitioning: · Copied another configuration: Network partitioning may be in use when it is unnecessary. For instance, you may have kept your previous Conventional TCP/IP configuration when you migrated to TCP/IPv6, so you have just a few interfaces in a partition, or you may have copied a configuration directly from the TCP/IPv6 manual, whose examples illustrate the new LNP feature, even though your NonStop system is connected to a single network. You can migrate these configurations to a single partition and you do not need more CLIMs than the adapters you are using, maybe even fewer.

5

· Conventional TCP/IP limitations: If you needed more bandwidth or fault tolerance than the four interfaces allowed by one Conventional TCP/IP process could provide, or you wanted to spread the TCP/IP load among multiple processors, you may have configured multiple processes and then created an independent network for each. CIP allows more interfaces and a better spread of processor load, so you can merge the networks, consolidate partitions, and not need more CLIMs than adapters. · Round-robin filtering limitation: TCP/IPv6 has a limitation that only one application in a processor can use round-robin filtering on a port. You may have worked around this by creating a separate partition for each additional application that needs to run on a processor. CIP does not have this limitation, so partitions created for this purpose are not necessary. You can merge the partitions and may not need more CLIMs than adapters. · Confining applications that bind to INADDR_ANY: Server applications that are not configured with a specific IP address on which to accept incoming TCP/IP requests probably bind to INADDR_ANY, which allows the application to accept requests on all IP addresses in the partition. You may be using network partitioning to confine such applications to a subset of the addresses on the system. However, many third-party applications can be configured to bind to a specific address, so they accept connections only to that address, much like binding to INADDR_ANY on a partition with one interface (see figure 2). For instance, the TCP/IP parameters used by the iTP Secure WebServer are configured in the Accept command. If this command has no address option, the WebServer binds to INADDR_ANY, but if you add an address option with an IP address, it binds to just that address. You may need to research a little to find how to do this for third-party applications, or invest development time to enhance your own applications, but if you succeed, you can consolidate partitions and get better use of your network.

Figure 2: Applications that bind to INADDR_ANY

Applications that bind to INADDR_ANY can be changed to bind to a specific address instead of using network partitions to confine the scope of their binds.

6

· Connected to independent networks with no IP address conflicts: You may have used multiple partitions if your NonStop system is connected to independent networks, but those networks do not and are never expected to have any IP address in common among them. You can consolidate such partitions, but if a network has addresses that do not have the same subnet ID as a local address on the interface connected to the network, or if more than one network has addresses with the same subnet ID, you will need to configure static routes so the CLIMs know which interface to use for particular destinations. No new routes are needed if each network has its own unique subnet ID that matches the subnet ID of a local address on the connecting interface (figure 3).

Figure 3: Separate networks with no IP address conflicts

Separate networks with no IP address conflicts can use static routes instead of network partitions. Net A needs no new routes since its addresses have unique subnet IDs that match the local addresses. Net B has addresses with a subnet ID different from that of the local address, so needs a route for each such address. Net B and Net C have addresses with the same subnet ID, so one of the networks needs to use host routes.

· Multiple server applications on the same IP port number: If you have multiple copies of a server application that listens to a standard IP port number, you may have used the same IP address for each and partitioned your network so all clients can connect to the same address and port; the partitioning directs them to the closest server. You may be able to use round-robin filtering instead; in CIP, it allows any number of applications spread across all the processors of a system to listen to the same IP address and port, then spreads incoming connections among all of them. If not, your NonStop system is connected to independent networks that have common IP addresses. You may get better use of your resources if you merge the networks and use that port number with different IP addresses. The remote clients that connect to these applications would then need to be configured to use different addresses.

7

· Connected to independent networks with IP address conflicts: If your NonStop system is connected to independent networks and more than one of the networks unavoidably has or might have the same IP address, then you must continue to configure a separate partition for the interfaces that connect to each network. However, all the interfaces that connect to the same network can be in one partition. If you used multiple partitions for networks that do not have conflicting addresses, you can consolidate those partitions. If you spread the interfaces in a partition over several adapters to reduce the effect of an adapter failure, you can consider putting the interfaces on one or two CLIMs (figure 4) and use both bonding interfaces and CLIM-to-CLIM failover to get outstanding failover coverage (figure 5).

Figure 4: Consolidating interfaces

Consolidating interfaces for a partition that were spread among multiple adapters onto a single CLIM can reduce the number of CLIMs needed. Unused interfaces are available for future growth of the partition.

8

· External requirement to use separate resources: You may have a contractual or legal requirement that data for an application uses separate resources or interfaces from other data. Network partitioning is one way to meet this requirement, but it is not the only way. You can get the same effect by assigning a separate subnet ID for each such application, then creating IP addresses with that subnet ID on the desired interfaces and configuring the routing tables to use those interfaces for that subnet (figure 3). This configuration shares a CLIM among multiple applications, which may violate your requirements, but is not very different from sharing an E4SA or G4SA adapter. If you must continue to use network partitioning and spread the interfaces in a partition over several adapters, you can move the interfaces onto one or two CLIMs with bonding interfaces and CLIM-to-CLIM failover (figures 4 and 5). You may have a reason for fine-grained network partitioning previously not covered. These scenarios should give you ideas on how to fit CIP into such an environment without using a large number of CLIMs--mainly to reduce the number of partitions if possible, and move all the interfaces in a partition together onto a few CLIMs, taking advantage of interface failover.

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 5). 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 interface 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 it cannot migrate TCP or SCTP connections. On the system experiencing failover, sockets with connections get an ECONNRESET error on the current socket operation, or on the next socket operation if there is no current 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.

9

Figure 5: CLIMs added for both types of failover

CLIMs are added for both types of failover to the configuration in figure 4. 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. Note that interfaces to Net C were added to take full advantage of failover.

10

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 TCPIP SCF command that must be redirected to a process other than the SAM process:

Conventional TCPIP Command ABORT ROUTE ABORT SUBNET ADD ENTRY ADD ROUTE ADD SUBNET ALTER SUBNET DELETE ENTRY DELETE ROUTE DELETE SUBNET INFO ENTRY INFO ROUTE LISTOPENS PROCESS NAMES ENTRY NAMES ROUTE START ROUTE START SUBNET STATS PROCESS STATS ROUTE STATS SUBNET STATUS ENTRY STATUS PROCESS STATUS ROUTE STOP ROUTE STOP SUBNET TRACE SUBNET Target process for equivalent command Parallel TCP/IP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP TCPSAM TCPSAM $ZZTCP TCPSAM $ZZTCP $ZZTCP TCPSAM TCPSAM TCPSAM $ZZTCP TCPSAM TCPSAM $ZZTCP $ZZTCP TCPSAM NonStop TCP/IPv6 $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP $ZZTCP TCP6SAM TCP6SAM $ZZTCP TCP6SAM $ZZTCP $ZZTCP TCP6SAM TCP6SAM TCP6SAM $ZZTCP TCP6SAM TCP6SAM $ZZTCP $ZZTCP TCP6SAM Cluster I/O Protocols (n/a) CLIMCMD ifstop CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig CLIMCMD climconfig $ZZCIP or CLIMCMD netstat CLIMCMD climconfig CLIMCMD climconfig (n/a) CLIMCMD ifstart CLIMCMD netstat CLIMCMD route CLIMCMD netstat CLIMCMD arp $ZZCIP $ZZCIP or CLIMCMD climconfig (n/a) CLIMCMD ifstop CLIMCMD tcpdump

11

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 differences: · 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.

Relative product strengths and weaknesses

Conventional TCP/IP Strengths

· All platforms · ATM, Token Ring, · Remote sockets · Fault-tolerant sockets

Parallel TCP/IP

· Scalable architecture · Seamless interface

NonStop TCP/IPv6

· Scalable architecture · All platforms · IPv6 support · Seamless interface

Cluster I/O Protocols

· Scalable architecture · Offloaded protocol

and X.25 interfaces

failover

stack

· IPv6 support · SCTP support · IPSec support · Partial interface

failover

failover

· Faster tracking of

industry standard changes by CLIM only

Weaknesses

· No jumbo frames · Process bottleneck · No round-robin

· S-series only · No network

· No IP security

· Network partitioning · No connection

partitioning

filtering

· No tracking of

failover across CLIMs

· No interface failover · No tracking of

industry standard changes

industry standard changes

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.

12

References

For the NonStop Networking Overview (which explains the IP CLIM and other NonStop networking products), visit: http://www.hp.com/go/nonstop-docs For the planning guide (which has high-level information about the IP CLIM), visit: http://www.hp.com/go/nonstop-support-docs (internal) For the Cluster I/O Protocols (CIP) Configuration and Management Manual (which has detailed configuration information about the CIP subsystem, which supports the IP CLIM), visit: http://www.hp.com/go/nonstop-docs For the HP NonStop TCP/IPv6 Configuration and Management Manual (which has detailed configuration information about the TCP/IPv6 subsystem), visit: http://www.hp.com/go/nonstop-docs For more information, please visit: www.hp.com/go/nonstop

© Copyright 2009­2011 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, Created January 2009; Updated March 2011, Rev. 2

Information

IP CIP compared to other HP NonStop TCP/IP products (US English)

13 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

896462