ACSLS issue with Netbackup

[jdespres]

Background:

Master = Solaris 2.6 NBU 4.5 FP4
Media = Solaris 2.8 NBU 4.5 FP4

ACSLS = Solaris 2.6 6.0.1

Total Media Servers = 15

Attempting to fire up a new Media server accross a NAT'ed switch...

Original IP = AA.BB.CC.DD, NAT'ed IP = EE.FF.GG.HH

Netbackup master seems to be OK with it. Since the drives are directly attached to the Media server....

The ACSLS server on the other hand recieves the packets ok but wants to send them back to the media on the wrong IP.

That is The ACSLS Server wanst to the return packets to the original IP. That IP gets rejected on a switch!

The end result is that the drives stay in a AVR mode and the robot never gets initialized....

The only Item I have changed on the ACSLS in the past when I configured the other Media servers was the hosts file.

Following are the logs I'm seeing on the ACSLS:

2004-01-30 09:41:27 CSI[0]:
2079 I csi_build_response.c 1 242
ONC RPC: st_send_packet(): Sending first response to client 10.49.20.35.

2004-01-30 09:41:54 CSI[0]:
2085 N csi_client_proc.c 1 145
ONC RPC: csi_client_proc(): status:STATUS_NI_TIMEDOUT;
Discarding packet for client 10.49.20.35 with SSI identifier of 1.

2004-01-30 09:41:54 ACSSA[0]:
1432 N sa_demux.c 1 273
Server System network interface timeout.

2004-01-30 09:42:18 CSI[0]:
2085 N csi_client_proc.c 1 145
ONC RPC: csi_client_proc(): status:STATUS_NI_TIMEDOUT;
Discarding packet for client 10.49.20.35 with SSI identifier of 1.

2004-01-30 09:42:18 ACSSA[0]:
1432 N sa_demux.c 1 273
Server System network interface timeout.

Joe Despres...........

 

[sgoldsmith]

Based on the info above it looks like you have the same problem as when you try and fire ACS data through a firewall. ACS uses a random port (within a certain range) for each communication thread that is started. As a result when a firewall (or other network block) is placed in the way ACS data can not pass.

To resolve this there are 2 possiblities, open the firewall / network block to allow for the port range that ACS uses to pass through.

Or install StorageTek's LMG (library management gateway) this runs as a Client adapter (installed on all the Media servers) and a gateway (that usually runs on the ACSLS server). Any ACS commands from Netbackup get intercepted by the Adpater software on the Media server and get encrypted to XML and sent to the ACSLS server via port 80. The gateway expects this traffic on port 80 and decrypts the XML and performs the ACS command.

The major issue to this maybe that StorageTek may be unwilling to sell you LMG as a standalone as there was talk of removing it from sales and intergrating it into ACSLS 7.0 - so you may need to upgrade.

All the baove maybe a incorrect for your problem (as LMG is deigned for a firewall based environment). ACSTEST and simple telnet / ping commands should alert you to any obvious communication issues.

Hope this is of some help.

Simon Goldsmith

 

[jdespres]

The ports have all been opened up......

We don't have any support for the ACSLS.... Bummer!

The communications seems to be OK....

Just not sure why / how ACSLS whant to talk back to the Original IP and not the NAT IP. The hosts file only has the NAT IP.

I bet the Original IP is imbedded in the messages that make it out to the ACSLS

Will acstest capture the attention of the acs? I have 4 other masters talking to the same ACSLS. I don't want to disturb the others...

Thanks for the response!

Joe Despres

 

[sgoldsmith]

ACSTEST won't disturb the other Masters, just don't leave it connected too long. Its just really to confirm communication (using ACS commands) from the Media to the ACSLS server.

Based on what you said above it sounds like it could be a routing issue. That is the any traffic from the ACSLS server is being told to redirect in some way.

If all the ports are opened then communication should be fine.

 

[jdespres]

Got a fix for this issue.....

I put &quot;ACS_SSI_HOSTNAME = <IP>&quot; in vm.conf

And now my drives come up in ACS mode....

Now I need to find a time to bounce my Master servers processes! We usually do 12,000 backup in 3 days....