NetXMS Support Forum

Hi!

Switch reports interface operational status as 2 (down) for 2 of them and 6 (notPresent) for other two on each unit. NetXMS server translates "notPresent" state into UNKNOWN status, this is why you see some of 10G interfaces as unknown. It's a question if this is a correct interpretation of interface state, or it should be translated into CRITICAL status, as for DOWN state.

Best regards,
Victor

Не смог подключится по SNMP, только на web интерфейс. Было бы очень полезно SNMP доступ получить тоже. По wireless bridge - а как у них выглядят интерфейсы?

I start working on that. Support for correct layout will be gradually added to the drivers. This probably will be slow process, as it requires extensible knowledge and/or search on internet for physical port layout of different switch models. But we will move in right direction

Best regards,
Victor

Hi!

No, it's actually is/was a bug in NetXMS. Information about connected peer node is stored in interface object itself, and supposed to be cleared when same node found on another interface. This bug should be fixed in 1.2.2, but if node move to another port was discovered before upgrade, peer information on old interface might not be updated. Keep looking if new stalled peer information will appear. If possible, try to do some tests - connect node to one port for few hours, ensure that it is shown on correct port, then reconnect to another port, and check again after few hours - it should corrrectly show node on new interface and nothing on old interface.

Best regards,
Victor

Quote from: DanG on July 27, 2012, 07:56:36 AM
What I find strange is that for all Windows PC's the interface object is unknown, NetXMS knows their IP but not their MAC. Windows machines with an agent installed do have correct interface objects, surly I don't have to install an agent on each machine to have it's MAC?

Currently NetXMS can obtain MAC address only directly from device, by SNMP or via agent. I plan to add setting MAC address for nodes without agent or SNMP based on ARP information. Hopefully it will be implemented in version 1.2.3.

Quote from: DanG on July 27, 2012, 07:56:36 AM
BTW, is there a way to obtain information about the progress of the auto-discovery?

No. There are feature request for that.

Best regards,
Victor

Quote from: djaksons on July 25, 2012, 10:01:17 AM
Хотел мониторить время работы от батарей но в программе нет переменной такого типа

Имеется ввиду TIMETICKS? Это обычный unsigned integer. Поставьте соответствующий тип в DCI, и все будет собираться корректно.

Quote from: SKYnv on July 26, 2012, 10:30:47 PM

Quote from: Victor Kirhenshtein on July 26, 2012, 10:07:21 PM
Хорошее описание по добавлению параметров получилось. Поставил как отдельный топик.

НУ тогда явно напрашивается раздел Best Practices или Tips and Tricks

Скорее wiki, но там русского раздела еще нет...

I'll try to fix it till next release.

Best regards,
Victor

Can it be that said printer was connected to port 20 before? Or it was always in port 2?

Best regards,
Victor

Either bug, or switch really does not provide state for these ports. Can you do nxsnmpwalk on .1.3.6.1.2.1.2.2 and send output to me?

Best regards,
Victor

Yes, alarm state should change to "Resolved".

Best regards,
Victor

Can you dump server objects by running command

nxadm -c "sh o" > file

and try to find records for problematic objects in that file, and send them to me?

Best regards,
Victor

Hi!

From the logs looks like a lot of IP addresses coming from node ormanage.orion.local (172.16.0.7). Log is wrapped, so I don't see beginning of the poll, but there are a lot of IPs from 172.16.47.xxx for example, almost each IP address. All these addresses coming from ARP cache. Check what this node really reports as it's ARP cache. To prevent this from happening you can disable discovery polling for that problematic node.

Best regards,
Victor

Yes, it could be useful. I'll add it as low priority feature request.

Best regards,
Victor

Hi!

Are you using 1.2.1 or 1.2.2 already? There was a major fixes and improvements regarding MAC address search in 1.2.2. If 1.2.2 is not working, can you please check MAC address table on your Cisco switch and ensure that it contains entry for your tape library?

Best regards,
Victor