BSAP Ethernet NRI Error Messages

Problem Description

Many Ethernet BSAP devices have a bug which makes them set the MEX and/or sequence number in NRI Ack messages to an incorrect value.

This will be logged as an error by ACM:

NRI Ack MEX mismatch: expected 12, received 32.

NRI Ack SEQ mismatch: expected 2, received 8224.

Since this usually doesn't mean that the NRI messages have failed, ACM doesn't retry them, but the error messages have been left in because they're useful in flagging another problem. If the errors for the NRI Ack message are being logged continually, what's likely happening is that ACM keeps sending an NRI table to the device because the device keeps setting a flag in the response message to request it. This situation may be occurring because the IP address of the computer on which ACM is running is not configured in the device as one of the device's NHP addresses. BSAP devices will only accept network routing information that is sent from one of their network host PCs.

If the NHP address is correctly configured and the problem persists, there may be a problem with the device port to which the NRI is being sent. Some device ports can't accept NRI tables or can be programmed to reject them. Sometimes the resulting situation is that the device needs an NRI table and sets the flag, but the device port to which ACM is connected won't process the table that's sent. So, the flag keeps being set and ACM keeps sending the NRI table.

Background

NRI stands for "Network Routing Information". An NRI message sends the BSAP node routing table and the IP addresses for alarm and RBE reports to the device. Once a device has the BSAP node routing table, globally addressed messages can be sent through that device to other devices that are connected to it. If this isn't needed the node routing table isn’t of much use, but most devices will ask for it anyway.

Alarm and RBE IP addresses can be configured in ACM, and they’ll be sent as part of the NRI message, but ACM doesn’t process alarms or Ethernet RBEs. These fields are only provided for customers who are also using some other program to which they want alarms and Ethernet RBEs sent.

Solution

To fix this, either connect to a different device port or reprogram the port you're using to accept NRI tables. If you can't do that, there's an option in ACM that will stop ACM from sending the NRI table when requested. In the ACM configuration, in the device's Time Sync tab, in the TS/NRT Options, deselect the "Send TS/NRT on Request" option. Doing this will mean that the device will never get the NRI it's requesting, but some devices will still process data requests anyway.

Certain ControlWave system variables, if set to TRUE, will cause the NRI table to be rejected (and then requested again and again).

Make sure these variables are set to FALSE to stop the repeated requests. This can be accomplished either by writing to them if allowed or through the device software.

@GV._NHP_IGNORE_NRT
@GV._P1_NRT_DIS
@GV._P2_NRT_DIS
@GV._P3_NRT_DIS
etc.