Dual TCP/IP Support

Dual TCP/IP is an option that can be purchased for the SL8500 and SL3000 libraries (herein known as the library). It provides two TCP/IP connections to the library. However, you can continue to use the library with only one of the two connections operational.

The purpose of dual TCP/IP is to automatically recognize and avoid a failing communication path. Since this is automated, there is no need for you to manually switch from an inoperative connection.

To use dual TCP/IP support on the library, the routing tables on both of the ACSLS server and the library must be managed using the “route" command. This forces a route to the defined network interfaces on the library which in essence, creates a one- to-one relationship between interfaces. The Customer Systems Administrator (CSA) changes the routing tables on the ACS server and the Customer Systems Engineer (CSE) updates the routing tables on the library. For further information on the UNIX “route" command, refer to the man pages on your ACSLS server.

Requirements

Coordinate with both your system administrator and network administrator to understand your current network environment, and to identify all necessary IP addresses in advance.
Coordinate with your system administrator to either configure your network interface, or to validate that it is configured properly.

Configuration

It is recommended that ACSLS keep two connections to the library open since ACSLS uses all active connections. If one connection is inoperative, ACSLS uses the remaining operative connection while continuing to try to re-establish communication on the failing connection.

The preferred configuration for dual TCP/IP implementations would be two network interfaces on two separate subnets for the ACSLS server, as shown in Scenario 1. This provides maximum throughput and minimum resource contention, with regard to network communications while adding a second physical connection, improving reliability.

To configure two TCP/IP connections to a single library, use the acsss_config utility or Dynamic Configuration (config). Enter the number (2) of connections that there are to the library and the IP addresses of the network devices. The SL3000 supports IPv4 connections.

The following scenarios provide examples for configuring the ACSLS server. For instructions on configuring the library dual TCP/IP feature, refer to the appropriate library System Dual TCP/IP Feature document.

The following scenarios use private subnet IP addresses and will not be the same in your environment. These scenarios assume that your network devices have been configured and are functioning properly.

Scenario 1 - Preferred Configuration

Scenario 1 is the preferred configuration for the dual TCP/IP feature.

In this configuration, the ACSLS server contains two network interfaces that reside on two separate subnets. The SL8500 or SL3000 has two network interfaces on the same two subnets as the ACSLS server.

Figure B-1 Preferred Configuration

Description of "Figure B-1 Preferred Configuration "

In this scenario, the libraries use a one-to-one relationship with the network interfaces on the ACSLS server in which the:

qfe0 interface on the ACSLS server only communicates with the eth0 interface on the SL8500 or SL3000.
qfe1 interface on ACSLS only communicates with eth5 on the SL8500 or SL3000.

Using the UNIX “route" commands, you force this relationship.

For Solaris: as user root, type the following commands:
```
route -p add 7.0.50 -ifp qfe0 192.168.0.254
```
```
route -p add 192.168.1.50 -ifp qfe1 192.168.1.254
```
The first route command routes any communication with 192.168.0.50 to go through qfe0 on the ACSLS server and then go through Router 1.

The second command routes any communication with 192.168.1.50 to go through qfe1 on the ACSLS server and then go through Router 2.
You can validate that the routes are in the routing table by typing:
```
# netstat –r
```

The first two entries are the ones that were just added. All communication with 192.168.0.50 will go through QFE0, and communication with 192.168.1.50 will go through QFE1.

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 Modular Library System Dual TCP/IP Feature document.

Example B-1 IPv4 Routing Table

Destination              Gateway       Flags  Ref  Use  Interface 
______________           ________       _____  ___  ___  _________ 
192.168.0.50             192.168.0.254  UGH    1    0    qfe0 
192.168.1.50             192.168.1.254  UGH    1    0    qfe1 
192.168.0.0              192.168.0.1     U     1    7    qfe0 
192.168.1.0              192.168.1.1     U     1    0    qfe1 
BASE-ADDRESS.MCAST.NET   192.168.0.1     U     1    0    qfe0 
default                  192.168.0.254   UG    1   33 
localhost                localhost       UH    4   77    lo0

Scenario 2

Scenario 2 shows:

ACSLS server with two interfaces on separate subnets from the library
SL8500 or SL3000 library with two network interfaces on separate subnets from ACSLS
Both ACSLS and SL8500 or SL3000 using a public network

Figure B-2 ACSLS and SL8500 or SL3000 Using a Public Network

Description of "Figure B-2 ACSLS and SL8500 or SL3000 Using a Public Network "

Using the UNIX “route" commands, you force this relationship.

For Solaris: as user root, type the following commands:
```
#route add 192.168.2.50 -ifp qfe0 192.168.0.254
#route add 192.168.2.50 -ifp qfe0 192.168.0.254
```
The default routes for the ACSLS remain the same. The routes within the subnets will know how to route communication to the libraries through the public LAN and you are still forcing the one to one relationship with the interfaces. Again, this is seen using the following command:
```
# netstat –r 
```

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/IP Feature document.

Scenario 3

In this scenario, there is one ACSLS server with one network interface on a separate subnet. The SL8500or SL3000 library has two network interfaces on two subnets that are separate from the ACSLS server.

Figure B-3 SL8500 or SL3000 with Two Network Interfaces

Description of "Figure B-3 SL8500 or SL3000 with Two Network Interfaces "

Remember: Configure the library routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/ IP Feature document.

Scenario 4

Scenario 4 shows:

Two Highly Available (ACSLS HA) servers, both with three network interfaces, two separate private subnets with the SL8500 or SL3000, and a third public network.
One SL8500 or SL3000 library with two network interfaces on the same two private subnets as the ACSLS servers.

Figure B-4 ACSLS HA

Description of "Figure B-4 ACSLS HA "

In this scenario, ACSLS HA uses two different servers with each using different network interfaces. This means that custom route entries must be added to both ACSLS servers.

For the Solaris user:

On ACSLS server 1, you would type:

route add 192.168.0.50 –ifp qfe0 192.168.0.254

route add 192.168.1.50 –ifp qfe1 192.168.1.254

On ACSLS Server 2, you would type:
```
route add 192.168.0.50 –ifp qfe1 192.168.0.254
```
```
route add 192.168.1.50 –ifp qfe2 192.168.1.254
```
You must add the IP addresses for both servers to the libraries' configuration. Refer to the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/IP Feature document.

It is important that you separate the libraries' network interfaces over two different subnets when on ACSLS HA. The purpose of a Highly Available environment is to build in redundancy and eliminate single points of failure.

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/ IP Feature document

Retaining Customized Routing Table Entries after a Reboot

Any customized routing table entries are lost after a system reboot. This is the nature of system routing tables and is expected behavior.

In order to support the Dual TCP/IP feature on the SL8500 or SL3000, it is necessary to add custom entries to the routing tables on the ACSLS server. When the ACSLS server is rebooted, all routing table entries are flushed and any necessary routes to the libraries are removed. Since this is the nature of the operating system, there are a couple of different ways to handle this situation.

Creating Scripts

You can create scripts to add custom routes to be initialized at boot time. See Adding Custom Route To Be Initialized At Boot Time for procedures.

These scripts can then be placed in the rc directory structure for automatic execution at boot time. Refer to your system documentation for details on the best way to implement this.

Use the ACSLS startup scripts to add your custom routing entries at boot up time. The startup scripts check for a file that contains customized route table entries. Any entries found are added to the routing table automatically using the UNIX route command. For standalone ACSLS installations, this is a desirable method to maintain route entries that are necessary for library support.

Important: This solution will not work if the ACSLS installation is a Highly Available ACSLS (ACSLS HA) environment. In this case, you must use the first method to maintain routing tables.

ACSLS HA handles system initialization differently than a standalone ACSLS server because it relies on Solaris Cluster to manage its clustered resources, which means ACSLS cannot be automatically started by way of the system RC mechanism at boot time. This is handled strictly by the Solaris Cluster agents with the S87ACSLS startup scripts never being used. Add a script with the appropriate “route add" commands and locate it within the /etc/rc2.d directory structure. It is highly recommended that anyone with an ACSLS HA environment engage Oracle Advanced Customer Support – preferably the same consultant that originally installed the ACSLS HA system.

Adding Custom Route To Be Initialized At Boot Time

To add custom routing entries:

cd to the following directory:

$ACS_HOME/data/external/ custom_routing.

This directory contains the template file custom_routing_tables.tpl.
Copy this file and change the file name to custom_routing_tables.
```
# cp custom_routing_tables.tpl custom_routing_tables
```
Edit (vi) the custom_routing_tables file and add your entries.
The file contains three fields.
- The IP address for the SL8500 or SL3000.
- The name of the interface on the ACSLS server that you want to establish the one-to-one relationship.
- The IP address of the default route for your subnet.
Follow the instructions in the custom_routing_tables comment section for the format.

Note:
Make sure that there are no blank lines.

When your server reboots, ACSLS is automatically initialized, and your custom routes are added to the routing table.
Verify all routes in the routing table with the following command:
```
# netstat -r
```

Refer to your UNIX man pages for complete documentation on both the route and netstat commands.

Removing routing commands

Use the route command to remove any special routing commands that have been added erroneously or are no longer needed to the earlier configuration.

Example: As user root, type the following commands:

# route delete 192.168.0.50 192.168.0.254

This says to remove the route to 192.168.0.50 (the SL8500 or SL3000) using the default route of 192.168.0.254. The route is then removed.