The Mapping Challenge
Similar to Hirschmann having Industrial HiVision, Westermo, Moxa, Antaira, Phoenix Contact, and Siemens are among other OT switch vendors that have their own packages.
Some of these are full blown Network Management Systems, one is called a Network Configuration Manager, but as you see in the pictures above they all do physical topology mapping, typically designed to map their devices for which they expectedly have more comprehensive understanding and control.
Why is physical topology mapping across multiple vendors difficult?
Did you notice I called out “comprehensive understanding”? Why is that important?
As an example, from the list of products in this post Moxa MxView ONE supports integration of 3rd party switches and it takes a pretty decent swing. See below we have integrated some Hirschmanns, a Cisco IE2000 (192.168.127.250), and a Stratix 5700 (192.168.127.249). But if we take a closer look - note those port numbers called out between the Cisco and the Stratix. The interface on the Stratix looks good as a familar Fa1/19 but the Cisco interface shows a less familiar port-010. Further investigation yields that Interface index 10 on the Cisco is Gi1/2.
So what’s actually happening here?
If we dive deeper we’ll discover “port-010’ is what the Cisco is putting on the wire over the LLDP (Link Layer Discovery Protocol - think neighbor discovery), and the LLDP table is where MXview is getting neighbor and port information. Unfortunately Moxa can’t really do much better than what the 3rd party device is providing.
And if that seems…unfortunate…keep reading, it gets a little worse.
In the above image, we ran only a “Strict Link Verification Mode” which instructs MXview to only interrogate LLDP info, so we know we’re only aiming for mapping switch-to-switch connections and ignoring hosts for now. To a degree, this limits the mapping “challenge” to the tomfoolery discussed above.
In the below image; however, we’ve added “Advanced Topology Analysis” which instructs MXview to also interrogate MAC forwarding tables, ARP caches, etc. to attempt to learn and ultimately show the connectivity of HOSTS as well. Below we see the host at the top left (which in actuality was only connected to the Moxa switch) showing connections to the Cisco and Stratix as well.
Why is this happening?
Let’s break down the Cisco first. The Cisco’s MAC table entry for that host would be on its link facing the Moxa (its’ port-009/Gi1/1) but when reading the MAC table over SNMP MXview sees this MAC on that Cisco’s “interface 1”, is unable to reconcile that MAC table “interface 1” and LLDP advertised “port-009” are actually the same interface and ultimately, draws a second line as if “interface 1” is a separate physical interface on the Cisco.
Similarly on the Stratix, the Stratix’s MAC table entry for that host would be on its link facing up to the Cisco (its’ Fa1/19) but MXview reads the MAC table entry on “interface 19”, is unable to reconcile that these also are actually the same interface and then…draws yet another line.
I want to be clear here - my point with all the above chaos is NOT to pick on MXview ONE but to provide a clearer picture of the challenge of physical topology mapping when attempting to do it across multiple vendors.
No standardization of LLDP payloads (Hirschmann supplies Port IDs and link speeds, the Stratix supplied a friendly port name, the Cisco supplied a less friendly interface index)
I have also seen these LLDP payloads change firmware to firmware.
I have also seen these LLDP payloads be inconsistent even within a vendor across different product lines.
No consistency between interface aliases presented via SNMP in LLDP vs MAC tables
None of this should surprise us since we can’t even enumerate interfaces consistently!
The mapping vendor truly has to commit non-trivial effort into properly mapping each vendor AND play whack-a-mole if a switch vendor makes a change. In full transparency, we’ve seen a switch vendor tool fail to map THEIR OWN SWITCHES properly after some change was made at the switch level; the whack-a-mole game even exists IN HOUSE between the mapping software team and the switch firmware team within one company!
Could one of these tools be good for you, though? Absolutely. In general your chances of success increase exponentially if the tool you’re using is from your switch vendor. I hate to be the one suggesting you go all in with one vendor, but I do want to help you understand what comes with that decision.
Commercial Notes
As of October 2025, below is the commercial situation around these offerings:
Westermo WeConfig - A free version is available for download below, while a premium version with extended features such as L3 routing, security, scripting, and reporting features will be offered via subscription.
Moxa MxView One - Per IP Host Device Managed. paid license Free 90 day trial available.
Antaira aNMS - Currently on 1.x and free. Antaira has suggested it may move to paid once it’s feature set has been built out a bit more.
Phoenix Contact FL Network Manager - paid single license per instance.
Siemens SINEC NMS - paid license
We’re not done yet. Stay tuned as the series continues…