Topology is not creating links for certain switches

[Arctica67]

I need some help to understand why iMC sometimes, for some switches do not create the link the switches.
In most of our locations this works just fine. But here is an example where it doesn't work good at all:

This site  was done about 2 years ago, they have recently new Aruba HPE 2530-48G POE+ switches. They are all on same firmware and same configuration. The one that does show link topology says this:

And all the other ones that show no link topology says this:

But this is where I get stuck. WHY does it say that iMC do not use lldp when the switch supports it?

All switches have CDP and LLDP enabled. For the switches that do not show the topology link in iMC, if I do a SHOW CDP NEIGHBOR DETAILS they do show the correct connections in the CLI.

I am using iMC PLAT 7.3 (E0705P07) I have these settings in System:

I just recently changed "Enable STP Link Calculation" to "No" after a tip on this forum, but hat did not change anything.

Any hints or help you could give so that we do not have to manually create the links between the switches?

[jguse]

Hello,

Please try disabling CDP on the 2530 switches, then synchronize them in iMC and see if that helps. I've seen issues before where inconsistent results between LLDP and CDP MIB on AOS switches prevents iMC from calculating the links, and it's recommended to run only one neighbor protocol (LLDP or CDP) at a time.

Hope that helps. Let me know if it doesn't and I'll post a few more steps you can take to troubleshoot the topology.

[Arctica67]

Hi Justin,

Many thanks for your feedback.
I did a super-easy script that executed the following:

no cdp run
write mem

It ran successfully on all switches. Then i did "synchronize" and "refresh" on all the switches. But unfortunately the links do not show up for those switches where it is missing. And "Topology Diagnosis" still says lldp is used by the switch but not by iMC.

What is even more strange was that I talked to a colleague of mine that intially did draw this topology. He said that the links had worked flawless in iMC for this site until I updated iMC to the latest version. Is there any chance that the update could have caused this? Could it be a bug?
The update itself from iMC_PLAT_7.3_E0705 to iMC_PLAT_7.3_E0705P07 did not report any issues at all.

Any more advice or hints would be very much appreciated, thanks a lot!

[jguse]

Hello,

Sorry for the delay as I was off last week. It could be a bug, though I don't see any issues on my lab topologies on P07 which also includes 2530 models with numerous links. I'd suggest troubleshooting further by looking through some logs.

To get started you will need the following:

1) Device IDs of the devices between which you know a link exists, but is not shown. You can get the DevID quickly from Device Details by checking the URL text from one of the pop-up windows like "Telnet/SSH Proxy" or "IP/MAC Learning Query"... or access the API interface /imcrs with GET /plat/res/device, which shows all devices including their IDs.

2) L2 Topology, gathered via System Configuration -> Data Collection by selecting the "l2Topo dump information" checkbox. You don't need any other data from this, so only fill in required fields, with option "Save to Server" to save it in iMC's tmp folder. Extract the archive and you should find an l2topo.txt. That file contains all the details about the network topology, in particular showing you which information has been retrieved via the different protocols, and why each link was drawn.

3) imcl2topodm log on DEBUG. You can set it to DEBUG via System Configuration -> Log Configuration page, then synchronize two devices between which a link exists. Download the log (not the imf log, that won't be useful) from the same Log Configuration page afterwards and have a look (and set it back to INFO level). Any issues gathering certain protocol data from your devices and creating links should be logged here.

Once you have that information you could start with the l2topodm log. Does iMC show an error about getting LLDP information for your device ID? Here is an example where I synchronized a Windows VM monitored via SNMP, which doesn't provide anything in terms of neighbor protocols, so you can see the errors:

2020-11-02 19:26:19.068 [INFO (0)] [THREAD(7648)] Can't get bridge address of dev(173), get vblist failed
2020-11-02 19:26:19.069 [INFO (0)] [THREAD(7648)] The new learned macs of dev(173) is empty
2020-11-02 19:26:19.070 [INFO (0)] [THREAD(7648)] The old learned macs of dev(173) is empty
2020-11-02 19:26:19.070 [WARNING (0)] [THREAD(7648)] unknown device mib style, dev is <Device-IP> and mib style is -1.
2020-11-02 19:26:19.072 [ERROR (0)] [THREAD(7648)] [CL2TopoSNMPOper::getLLDPLocMac]:iGetNextVbValue Failed when get OID_lldpLocChassisIdSubtype, devID: 173
2020-11-02 19:26:19.072 [ERROR (0)] [THREAD(7648)] unknown device mib style., devID: 173
2020-11-02 19:26:19.073 [ERROR (0)] [THREAD(7648)] [CL2TopoSNMPOper::getCDPStatus] iGetNextVbValue Failed when get cdp enable information. devID: 173
2020-11-02 19:26:19.074 [ERROR (0)] [THREAD(7648)] [CL2TopoSNMPOper::getLLDPInfo]:iGetNextVbValue Failed when get OID_lldpLocChassisIdSubtype, devID: 173
2020-11-02 19:26:19.074 [ERROR (0)] [THREAD(7648)] [CL2TopoSNMPOper::getStpDesignatedBridges]:Stp disabled, devID: 173
...

Those 'errors' above generally mean that iMC could not read the information via the standard SNMP MIBs like LLDP-MIB from your devices. You can check all the information iMC managed to obtain from your devices using L2topo.txt file with the Device IDs - this lists every device in iMC one by one by the ID, along with all learned neighbor information. Here is what the device shown in the log above looks like:

    DevID: 173
        SymbolID: 1391
        IP: 10.196.72.231
        IPMask: 255.255.254.0
        NeighborChangedID: -1
        STP Status: 2
        Macs: 
            <Dev-MACs>
        CDP/NDP Neighbor Info:
        LLDP Neighbor Info:
        STP Neighbor Info:
        Lag Info:
            LagType: 1
        MacAddress learn Info:
        WWN learn Info:
        bcs unit Info:
        Router If Info:
            IfIndex: 12            IfDesc: vmxnet3 Ethernet Adapter            IP: <Dev-IP>            IPMask: 255.255.254.0            Mac: <Dev-MAC>
        IP Address:
            <Dev-IPs>
        Base Port(PortNum->IfIndex):
        DismanPing Flag: 0 DismanPing DestIP: 0.0.0.0
        CategoryID: 2
        3LayerDev: 0
        MibStyle: -1
        FdbVlanMap(FdbID->VlanID):
        CiscoVlanID:
        DTSubIf:
        HostIfMac(Mac->IfDesc):
        HostIfWwn(Wwn->IfDesc):
        LinkInfo:
            LinkID: 157919 LinkLeftSymbolID: 1391 LinkLeftIfDesc: vmxnet3 Ethernet Adapter LinkRightSymbolID: 1054 LinkRightIfDesc: GigabitEthernet4/0/27 LinkType: 0 LinkCaclType: 4

As you can see the information gathered for this VM is quite limited, hence the errors. However it is still able to get one link drawn from "LInkCaclType: 4", which refers to L3/routing link calculation.

On a network switch you should see a lot of information under fields like LLDP Neighbor Info: and MacAddress learn Info: fields, and resulting links under the LinkInfo:, if iMC was able to gather relevant information from the MIBs and calculate the links. For reference the Link calculation types are LLDP - 0; CDP/NDP 1, STP - 2, MAC Addresses - 3; Routing Interface - 4.

If you see both LLDP and CDP information here for the same device, despite one protocol being disabled, then iMC probably failed to delete the old neighbor protocol information, and I would suggest trying to delete and re-add the affected device to iMC.

If you don't see any LLDP or CDP details, make sure the LLDP-MIB or CDP-MIB are accessible via SNMP on your devices (try snmpwalking them etc).

Hope that helps you to progress with your missing links.