Axel WOLF 1MS, User Manual, Page: 143 / 229

TECHNICAL APPENDIX
| TECHNICAL APPENDIX 143
16.7 APPENDIX G
– WOLF 2MS CONSIDERATION ON FW REL 1.2.1
In latest Wolf 2MS Firmware Release 1.2.1 has been improved and fixed the following features.
1. Highlights
-
Bug fix about issue concerning reboot and related issues
-
Bug fix about audio parameter saving
-
During NMS parameter change operation a bug was blocking the SNMP
-
Label correction of NMS-3
-
Has been added the information that trap-timeout and trap-retry work only in informV2 mode
-
Improved the trap retry from 100 to 1000
-
Tested Trap behavior with no Ethernet connection
2. Information about new firmware rel.
a. Only if has been selected InformV2, traps are automatically managed and repeated until an acknowledgement
has been received by NMS system.
b. Informv2 protocol provides as reported below: informV2 this protocol provides:
-
The agent, in this case wolf2ms should try again with a certain time period defined trap-timeout and return
to N times (trap-Retry) the same trap if it does not receive an ACK (acknowledgement) from the NMS.
Scenario -1 example:
if we set (Trap-Type:informV2, Trap-Timeout:10, Trap-Retry:360) we are going to set Wolf 2MS to retry for about 1 hour
to find an ACK from NMS server. All the traps are queued waiting for a response
with the above example by disconnecting the network cable for a time below 1 hour, and creating events, as soon as
cable has been reconnected (or Server has been closed and the opened again) all the traps queued are delivered.
If the timing in sec is exceeded (Trap-timeout*Trap-Retry) all the traps will be lost.
c.
Trap order is not granted as mentioned in the protocol, because it’s a delivery retry. The traps arriving is
determined by the Ethernet link come back, each trap contains all the timing information of the events so the
information can pass with no problem.
d. We have done some test by disconnecting the network until 30 minutes and all the workflow is perfectly
granted.
e. Using v1 or V2simple mode there is a simple trap delivery
3. Trap replay:
Wolf 2MS also supports trap-replay features replay (iTrapReplayEnabledTrapsReq). The server knows that the
synchronization could be lost and can ask to the agent (Wolf 2MS) all the variation that has been happened about issue
and alarms on the trap enabled. So a trap comes resend for each status variations that has been happened
Scenario -2 example:
The system works this way: the informV2 mode must plug gaps and short causal connection. Long connection
interruptions should be managed by the NMS server with a trapReplay request. Now the maximum time is 60 * 1000
seconds. So it could be managed until almost a day's lack of linkage.
Note:
If you change the parameters of the NMS pages, these become active 20-30 seconds later.