NetXMS Support Forum

Hi!

So initially zone is without proxy? Try to set this node as proxy for the zone, then run full configuration poll on it. Also please try to set debug level 6 on server for tag poll.*, and check server log after running status and configuration poll.

Best regards,
Victor

Hi,

most likely you'll have to look at NXSL extensions, data collection related functions are in src/server/core/dc_nxsl.cpp. Look for F_GetDCIValues - it is implementation of getting history for single value DCIs, and GetDCIValueImpl - it will give you idea how to return table value as NXSL object. Then you will need code to unpack table values. You can take a look at src/server/core/session.cpp, method ClientSession::getCollectedDataFromDB - you will be interested in code part around call Table::createFromPackedXML.

Best regards,
Victor

Hi!

There are few bugs that contribute to this problem. First is incorrect data reported by vCenter in ipAddressTable:

.1.3.6.1.2.1.4.34.1.5.1.4.172.17.128.20 [OBJECT IDENTIFIER] = .1.3

It should be either .0.0 or valid OID from ipAddressPrefixTable (.1.3.6.1.2.1.4.32). Combined with bug in NetXMS server that does not check for validity of this OID and just using last element (it should have done scan of ipAddressPrefixTable instead, as in .0.0 OID case) it produced /3 network mask (because in valid OID from ipAddressPrefixTable last element is prefix length).

Unfortunately just fixing this issue in NetXMS server is not enough, because ipAddressPrefixTable reported by vCenter is incorrect as well. OID

.1.3.6.1.2.1.4.32.1.6.2.1.4.255.255.127.0.24 [INTEGER] = 2

should have been

.1.3.6.1.2.1.4.32.1.6.2.1.4.172.17.128.0.24 [INTEGER] = 2

(with correct prefix as part of OID). I've checked on my vCenter - it returns exactly this incorrect value (255.255.127.0) no matter what actual subnet is.

I was able to add a workaround in server code for such situation - now server also attempts to scan inetCidrRouteTable for local routes and deduce correct prefix from there. It seems to work on my vCenter. This change will be included into next patch release.

Best regards,
Victor

Hi,

this supposed to be fixed in 3.9.235. Could you please provide screenshot of "Interfaces" tab for such device and event details for "duplicate MAC" event?

Best regards,
Victor

Тогда можно оставить использование transformation, просто скрипт заменить на вызов библиотечного скрипта в форме

return script_name::function();

В вызванном скрипте будет доступна переменная $dci.

$node - объект ноды с которой происходит сбор данных (https://www.netxms.org/documentation/nxsl-latest/#class-node)
$targetObject - объект ноды для которой происходит сбор данных (будет то-же что и $node если у DCI не выставлен source node)

В $ARGS (и в $1, $2, ...) будут параметры если в DCI скрипт указан со скобками.

Hi,

does NetXMS server has SNMP access to this Cisco device? Because normally it should read all configured addresses via SNMP and not attempt to create separate nodes for each known IP address.

If for some reason device is not accessible via SNMP, you can block secondary address in discovery filter. You can set discovery filter to script, and use script like this:

if ($node->ipAddr == "1.2.3.4")
   return false;
return true;


you can also use hook script Hook::AcceptNewNode for this, just add the following line to it:


return $ipAddr != "1.2.3.4";


(of course replace 1.2.3.4 with actual IP address).

Best regards,
Victor

Hi,

it depends on resources available. Developer that was working on it left the company, and currently we do not have any iOS developer onboard (and they are quite expensive as well). Ultimate goal is to have iOS client though.

Best regards,
Victor

Hi,

really nice idea actually, and should be fairly easy to implement. Added to my TODO list

Best regards,
Victor

Про сохранение запросов - пользователю нужно дать право "Manage object queries", но его невозможно дать через GUI в текущей версии. В следующем патч релизе мы это исправим.

Как минимум проблему с получением VLAN'ов я у себя повторил. Буду смотреть.

Вариант для проверки что устройство во всех указанных VLAN'ах:


with
vlanIdList = { %(4, 5, 8) },
vlanMatch = {
list = %();
for(v : vlans)
   if (v->id in vlanIdList)
list->append(v->id);
return list->size == vlanIdList->size;
}
type == NODE and hasVLANs and vlanMatch


Здесь vlanIdList содержит список VLAN'ов.

Проблему с access denied повторил у себя, похоже какой-то баг. Будем разбираться.

Попробуйте такой запрос:


with
vlanIdList = {
list = %();
for(v : vlans)
list->append(v->id);
return list;
}
type == NODE and hasVLANs and (100 in vlanIdList)


Я бы наверное сделал script DCI, который сам делает SNMP get или walk и по каким-то дополнительным признакам определяет правильный OID. Можно например хранить OID который читаем в атрибутах ноды, а если получили ошибку, то искать новый правильный и потом повторять чтение.

Можно использовать $dci->instance (то что мы видим в поле Instance в закладке Thresholds) или $dci->instanceData (то что вернул instance discovery).