NetXMS Support Forum

English Support => General Support => Topic started by: gmonk63 on March 06, 2020, 04:12:24 AM

Title: No Topology associations 3.2
Post by: gmonk63 on March 06, 2020, 04:12:24 AM
At work we switched to a different set of l2 switches and I do not get any topology info at all. But if I right click ->  info -> lldp I can see the neighbors. I can alos mib browse and see both local and remote lldp tables populated.  I though this all netxms needed to build the topo. The brand of switch is Moxa EDR 810 if that helps
Title: Re: No Topology associations 3.2
Post by: Victor Kirhenshtein on March 09, 2020, 10:34:29 AM
Yes, that should be enough for building topology. Could you set debug level to 6, run topology poll on few switches, and provide server log file along with console output for the poll?

Best regards,
Victor
Title: Re: No Topology associations 3.2
Post by: gmonk63 on March 10, 2020, 06:27:09 AM
I have attached the logs.  I think i know whats going on and it seems to be on the switch side but not 100% sure.  For each node that has been fully polled the interfaces all show as

ETHERNET PORT 1
.
.
ETHERNET PORT 10

However the lldptables from the switch show completely different port names

PORT1
.
.
PORT8
SFP-1GLXLC-T
SFP-1GLXLC-T

I can only get the topology to work if I uses alias's and SNMP SET the alias to match the lldp port name.  So setting port 9 and 10 to SFP-1GLXLC-T  on both switches will allow the connections to be found.  But I really don't want to script this up just to get things working and  if the SFP is changed it could end up being a different port name.  I would think Netxms would be able to just use the port index and FDB but maybe since LLDP is enabled that is not being used.   One other thing is the switched is a L3/L2 but is only on layer2 mode but is still discovered by netxms as being a router so the dot1qtpfdbtable does not return any entries only dot1dfdtable returns. Hope this helps and thank you for your time.

Gary 
Title: Re: No Topology associations 3.2
Post by: Victor Kirhenshtein on March 10, 2020, 10:37:23 AM
LLDP supports multiple options for port identification. In the log I see that those devices use identification type 5 - interface name, but from what you have described it looks like information provided through LLDP MIB is inconsistent with INTERFACE MIB. Could you please provide output of SNMP WALK for .1.0.8802.1.1.2.1.3.7.1 and .1.0.8802.1.1.2.1.4.1.1 on two connected switches?

Best regards,
Victor
Title: Re: No Topology associations 3.2
Post by: gmonk63 on March 10, 2020, 09:52:30 PM
Here you go. At this point I dont think this has anything to do with Netxms but any help would be much appreciated.  I have also emailed the switch support since the switch is clearly  advertising values that are not even configured in the tables.  I have a feeling this maybe on purpose since this particular vendor has a paid version of their own NMS
.


Thanks,

Gary 
Title: Re: No Topology associations 3.2
Post by: Victor Kirhenshtein on March 11, 2020, 10:48:37 AM
Yes, they LLDP implementation is full of inconsistencies. In LLDP local port table switch reports lldpLocPortIdSubtype as 7 (which is "local") and lldpLocPortId as number from 1 to 10, however when looking from other device we see that switch advertises same ports as Id subtype 5 ("interface name"). According to specification it is "a port identifier based on the ifName MIB object, defined in IETF RFC 2863.". However, it doesn't match actual interface name as reported via interface MIB.
Let's check walk results for OID .1.3.6.1.2.1.31.1.1.1.1 in case they report different names via ifTable and ifXTable. If this is not the case then all we can do is to add special handling in LLDP code for that particular type of switches.

Best regards,
Victor
Title: Re: No Topology associations 3.2
Post by: gmonk63 on March 13, 2020, 12:49:34 AM
Victor,

I attached the ifxtables in the previous message. Another thing I noticed is the FDB table does not list an interface. Is this also a result of the behavior of the switch. 

"MAC Address","Port","Interface","VLAN","Node","Type"
"CC:4E:24:BC:D1:2C","9","
Title: Re: No Topology associations 3.2
Post by: gmonk63 on March 25, 2020, 01:17:13 AM
Victor,

Is there anything I can do to provide a workaround to this on the netxms side of things? can I force the naming of these interfaces to match what is being sent by lldp.  I was given a newer firmware that was supposed to fix a known issues but I am still not seeing the topology in Netxms .  However The trial version of the vendors NMS works just fine.  But would rather not pay for an inferior product that doesnt have half the features of Netxms.
Title: Re: No Topology associations 3.2
Post by: Victor Kirhenshtein on March 27, 2020, 07:15:56 PM
One possibility is to change interface naming in netxms. You can do that either in configuration poll hook or by using interface name templates. If interface object names will match then topology builder should puck them up correctly. You can use macro that calls a script and replace ETHERNET PORT n with just PORT n.

Best regards,
Victor
Title: Re: No Topology associations 3.2
Post by: gmonk63 on April 15, 2020, 09:01:15 PM
Victor,

I have been going back and forth with them trying to have them fix the inconsistencies to no avail see their response below.

We have looked into the SNMP frames to find which OID NetXMS is polling from EDR-810 during auto-topology. We found out that modifying the subtype in LLDP does not fix the topology issue of NetXMS in our test. However, after discussing with PM, making EDR-810 compatible of NetXMS would be not in the specs and would be a CV request. In addition, we found that NetXMS polls dot1dBasePortIfIndex from EDR-810. However, the EDR-810 does not support dot1dBase-MIB. We have confirmed the auto topology can be done for EDR-810 with FW v5.6 in MXView

Is the fact that the switch does not support dot1dbaseportindex really matter.  Looking at the trial version of MXView  it doesnt seem to do anything more than what Netxms does and pretty much queries the same mibs except dot1dbase.  But it is able to find the topology no problem.   If this is somthing im just going to have to deal with. Is it possible to provide me with an example of a HOOK i can use to try and change the names of the interfaces after a poll. I have renamed the interfaces manually and the topology does seem to be found but it is very inconsistant every other poll will not find connections and it will never find a netxms agent that is connected to any port on the switch. However it does list the connections via info -> lldp but the port number is always off by one.  For example the agent will be connected in port 4 but lldp lists it as port 3.  So i do think there is some netxms lldp related issues going on.


Thanks
Title: Re: No Topology associations 3.2
Post by: gmonk63 on April 27, 2020, 10:12:21 PM
Please see  attached image.  I have tried two different NMS solutions that seem to have no problems finding the associations.  Maybe this should be a feature suggestion but is there a way to force netxms to use the FDB when building topology  for those switches that may not fully be compatiable with lldp.  I have seen several switch that in some way do not fully implement lldp  and this is just enough to prevent a topology in netxms.  But  those switches show all connections no problem in the FDB database. 


The attached is a topology map from opennms.  Netxms will never show the Desktop connection and only show switch connections between netxms-test and moxa pos switch  if I rename interfaces to match lldplocal port.


Title: Re: No Topology associations 3.2
Post by: Victor Kirhenshtein on April 29, 2020, 05:44:05 PM
Hi,

The fact that they do not support dot1dBase affects FDB reading. In FDB dot1dTpFdbPort supposed to contain bridge port number from dot1dBase. It looks like they just put ifIndex there. This we will be able to fix with device driver for those switches. I think that interface rename can be handled by driver as well. I think I'll be able to create driver for them in one of 3.3 patch releases if you can provide me access to test device or send required SNMP walks. You can contact me via PM regarding access or dumps.

Best regards,
Victor