HP MSL8096 IP config issues

[Thomas Biesmans]

We've got an MSL8096 configured and fully operational. The management port is configured in an 10.255.255.0/24 IPv4 range.

When i tried configuring the MSL for SNMP monitoring (e.g.: 10.255.255.21) I got an "Invalid address for SNMP IPv4 Target #" error.

When trying to enter DNS servers in this range (10.255.255.1 and 2), the values remained 0.0.0.0 for both DNS entries with no additional feedback (I tried using 10.254.254.1 and the MSL tested the connectivity to this address).

Is there a way to circumvent this faulty IP check? Is there, for example a way to edit the Config Save file (.dbb) and then restore it?
I haven't had any luck with finding an editor for this filetype.

[AnthonySN]

>> I got an "Invalid address for SNMP IPv4 Target #" error.

try assigning the same IP to a laptop/desktop in the same network

[Thomas Biesmans]

>> try assigning the same IP to a laptop/desktop in the same network

SASJ, there are several windows and esx servers configured in that range, all fully functional.

As a matter of trial and error I tried changing the main IP of the tape library from 10.255.255.228 to several unused IPs in the same network. This resulted in "Invalid IPv4 address!" errors.

I reckon this is caused by us using the all-ones subnet in the 10.* private range. Using the all-ones subnet (10.255.255.0/24) and subnet zero (10.0.0.0/24) is normally allowed. Only legacy applications could have problems with these networks.

Why can't the Command View MSL handle these? And how can I circumvent this without using another range?

[AnthonySN]

why not try a simple ip like 192.168.1.110

[Thomas Biesmans]

>> why not try a simple ip like 192.168.1.110

SASJ, that would be the easiest fix indeed. But the IP ranges have already been defined and the environment is configured and working in that range. Normally this range should not pose a problem.

I'd like to resolve the problem on the MSL itself. I can always use specific routes between the SNMP target and the MSL, a very messy approach, but I'd rather solve the problem on the faulty component.