SOLVED: DCE can't assign APC Secure Interface (ASI) for ATS AP7723?

[DCIM_Support]

Hi all!

Problem essence: in some ATS devices (for example in three of ten) for the unclear reasons it is impossible to setup the IP address of the server DCE in so-called section [SecureInterface]. And some methods of setup were tested.

1. This setup has to be performed automatically at detection of the device on the server DCE: it isn't setup, result negative, priority scanning at alarm doesn't become.

2. It is possible to register server DCE manually in device "config.ini" with the subsequent loading of this file, for example: 

   [SecureInterface] ; APC Secure Interface (ASI): ; To add an ASI trap recipient, list the IP address in the following form: ; :, ; CurrentASISubscriber=192.168.0.1 ; To remove an ASI trap recipient, list the IP or DNS name using the keyword: ; RemoveASISubscriber=192.168.0.2 ; To remove all ASI trap recipients, use the keyword, value pair: ; RemoveALLASISubscribers=yes Access=disabled AuthenticationPhrase=APC ASI auth phrase EncryptionPhrase=APC ASI crypt phrase TrapPort=9952 CurrentASISubscriber=192.168.0.1:162, ISX Manager

   The last line is that that is necessary for us. But after reboot of the device the last line simply disappears and "CurrentASISubscriber" doesn't remain.

3. It is possible to register manually above the specified setup by means of the "snmpset" command as it and does the DCE server, for example: 

   # snmpset -v2c -cprivate 192.168.0.130 .1.3.6.1.4.1.318.1.4.4.3.0 s "192.168.0.1:162,4" Error in packet. Reason: (genError) A general failure occured Failed object: SNMPv2-SMI::enterprises.318.1.4.4.3.0

   And in reply we receive here such mistake (therefore, it isn't strange that the DCE server can't make self this ASI-setup of the priority scanning device).

From all set of our devices of production APC for the unclear reasons such problem arose only on a quarter of devices, and, any sequence isn't observed. I.e., the reasons of emergence of this problem for me are a riddle...
Here the list of devices on which such ASI-problem was found:

• ATS AP7721 (only some devices of this model were ASI-problem);

• ATS AP7723 (only some devices of this model were ASI-problem);

• NetBotz 200 (all devices of this model were ASI-problem);

• PDPM277H (all devices of this model were ASI-problem);

• Symmetra 160K (0G-9354) (only some devices of this model were ASI-problem);

• Symmetra 48K (0G-9354) (only some devices of this model were ASI-problem);

• Smart-UPS 1500 (AP9619) (all devices of this model were ASI-problem);

• rPDU AP7857 (all devices of this model were ASI-problem).

And all devices have __ actual __ at the moment (November, 2015) the version of a microcode (online search and installation of updatings it was made by means of the DCE servers). And once again I will remind, that the ASI-problem wasn't solved by neither reboot, nor a poweroff/poweron of devices or resetting of their settings on factory default in any way.

SOLUTION:

The solution appeared very simple: in the configuration file of the ASI-problem device in section [SecureInterface] it is necessary to add the line "RemoveALLASISubscribers=yes" with the subsequent reboot of the device. Only after that it is possible to register successfully the IP address of the server DCE, and any of three below the specified ways:

1. in the standard way, in the way of new search of the ASI-problem device on the DCE server (with the marked checkbox of priority scanning);

2. manually, having stated in the configuration file in section [SecureInterface] the necessary IP address DCE server as it is described in a manual;

3. manually, by means of the "snmpset" command as it does the DCE server, i.e. having emulated operations of the DCE server.

The last way most simple and interesting, therefore I will give an example for acquaintance.

1. Initially, after reboot of the ASI-problem device with the option "RemoveALLASISubscribers=yes" we have no hidden trap receiver, i.e. any of the registered DCE server: 

   # snmpwalk -v2c -cpublic 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.2 SNMPv2-SMI::enterprises.318.1.4.4.2 = No Such Object available on this agent at this OID

2. Now we add as the hidden trap receiver the DCE server with the IP address 192.168.0.1 (actually, the DCE server executes similar command): 

   # snmpset -v2c -cprivate 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.3.0 s "192.168.0.1:162,4" SNMPv2-SMI::enterprises.318.1.4.4.3.0 = STRING: "192.168.0.1:162,4"

3. We check success of the executed command and we are convinced that now the server DCE is added and everything normally works: 

   # snmpwalk -v2c -cpublic 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.2 SNMPv2-SMI::enterprises.318.1.4.4.2.1.1.1 = INTEGER: 1 SNMPv2-SMI::enterprises.318.1.4.4.2.1.2.1 = STRING: "192.168.0.1:162" SNMPv2-SMI::enterprises.318.1.4.4.2.1.3.1 = INTEGER: 4 SNMPv2-SMI::enterprises.318.1.4.4.2.1.4.1 = INTEGER: 0

4. Similarly we add our second DCE server with the IP address 192.168.0.2: 

   # snmpset -v2c -cprivate 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.3.0 s "192.168.0.2:162,4" SNMPv2-SMI::enterprises.318.1.4.4.3.0 = STRING: "192.168.0.2:162,4"

5. Also we check result, being in parallel convinced that now we have in the list two DCE servers (as much as possible them can be to four): 

   # snmpwalk -v2c -cpublic 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.2 SNMPv2-SMI::enterprises.318.1.4.4.2.1.1.1 = INTEGER: 1 SNMPv2-SMI::enterprises.318.1.4.4.2.1.1.2 = INTEGER: 2 SNMPv2-SMI::enterprises.318.1.4.4.2.1.2.1 = STRING: "192.168.0.1:162" SNMPv2-SMI::enterprises.318.1.4.4.2.1.2.2 = STRING: "192.168.0.2:162" SNMPv2-SMI::enterprises.318.1.4.4.2.1.3.1 = INTEGER: 4 SNMPv2-SMI::enterprises.318.1.4.4.2.1.3.2 = INTEGER: 4 SNMPv2-SMI::enterprises.318.1.4.4.2.1.4.1 = INTEGER: 0 SNMPv2-SMI::enterprises.318.1.4.4.2.1.4.2 = INTEGER: 0

   Right there it is possible to view the configuration file of our device and to be convinced that at section [SecureInterface] also there are two similar records with IP addresses of our DCE servers. I.e. that we also achieved :-).

6. Now we will check, whether our DCE servers from the list of the hidden trap receivers are removed and we will execute here such command as it and does the DCE server: 

   # snmpset -v2c -cprivate 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.3.0 s "192.168.0.2:162,2" SNMPv2-SMI::enterprises.318.1.4.4.3.0 = STRING: "192.168.0.2:162,2"

7. Further we check and we are convinced that the server with the IP address 192.168.0.2 is already not present: 

   # snmpwalk -v2c -cpublic 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.2 SNMPv2-SMI::enterprises.318.1.4.4.2.1.1.1 = INTEGER: 1 SNMPv2-SMI::enterprises.318.1.4.4.2.1.2.1 = STRING: "192.168.0.1:162" SNMPv2-SMI::enterprises.318.1.4.4.2.1.3.1 = INTEGER: 4 SNMPv2-SMI::enterprises.318.1.4.4.2.1.4.1 = INTEGER: 0

8. Similarly we delete from the list the last from DCE servers with the IP address 192.168.0.1 with this commands: 

   # snmpset -v2c -cprivate 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.3.0 s "192.168.0.1:162,2" SNMPv2-SMI::enterprises.318.1.4.4.3.0 = STRING: "192.168.0.1:162,2"

9. And further simply we check and we are convinced that now on our device it isn't registered any hidden trap receiver: 

   # snmpwalk -v2c -cpublic 192.168.0.139 .1.3.6.1.4.1.318.1.4.4.2 SNMPv2-SMI::enterprises.318.1.4.4.2 = No Such Object available on this agent at this OID

That's it and very thanks for the support :-).

P.S.: after all, I found the solution of this ASI-problem earlier than an paid official support service of APC by Schneider Electric :-). Really I only who dealt with such unique and anybody yet not found ASI-problem?..

(CID:104173592)

[DCIM_Support]

Hi spezialist - thanks for sharing 🙂

(CID:104173698)

[DCIM_Support]

It is very pleasant to be useful to community :-).

Since the beginning of 2013 I have a quantity of various useful information and practical decisions on DCE. Therefore, I will also try further the most interesting to publish for a public review here.

P.S.: Stine, at me it is impossible to format with left alignment the text in code blocks in any way :-(. When editing code block everything looks ideally (left alignment), and after saves for some reason there is an center alignment of the text. Why? Very thanks for the support.

(CID:104173961)

[DCIM_Support · Accepted solution]

Thank you for letting us know about the left alignment in the code block. I don't know why it does that, but we are looking into it 🙂

(CID:104173960)

[DCIM_Support]

🙂 Stine, and I here several times changed formatting and quitted nothing! Well though it is pleasant that I helped to find one more bug :-).

Stine, please, tell me please when this bug is corrected. Very thanks for the support.

(CID:104173964)

[DCIM_Support]

Sorry to hear that. I will let you know when it is corrected 🙂

(CID:104173965)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.