3 years ago
Manual topology mapping
After years of suffering with the horrific (and broken) topology mapping, how about just giving us the ability to create our own dependencies/maps, similar to The Dude or MangeEngine's OpManager?
After years of suffering with the horrific (and broken) topology mapping, how about just giving us the ability to create our own dependencies/maps, similar to The Dude or MangeEngine's OpManager?
AnonymousmichaeldA11eyAny update on this? We've got a problem where we want to have Ruckus Unleashed APs show up in the Topology Maps, but because Unleashed is not supported with LM data, property or topology source modules, it's more challenging. It's not difficult to identify the MAC addresses from the Unleashed "Master" for all the APs -- we can see them in a snmpwalk.
Even if there was simply a way to import a CSV of whatever data, and have it impact the topology map, that would be an ok work around, but you can touch the necessary properties to have them show up on the map, unfortunately.
Maybe we're going about this the wrong way, but we're finding it's non-trivial to create a new module set to support Unleashed. We're just looking for these APs to attach themselves to the write parent switch in topology. For the APs, just that and a ping if they are alive is all we care about.
Ok, maybe this is a slightly different topic then.
I don't know about Rukus. But...
Topology relies on two things: 1) ERIs and 2) TopologySources or manual mapping.
ERIs are simply all the names by which a device may be identified by other devices on the network. So, all the MAC addresses on a device would be ERIs. If you add the Rukus devices into LM and enable SNMP, it's likely the built in ERI source(s) would pick up the MAC addresses and add them as ERIs on the devices. ERIs can be defined on the device level or the instance level so that a device can be connected to an instance which is connected to another instance which is connected to another device.
Then you can either automatically connect them or manually connect them.
To automatically connect them, you need to query a device that knows about the relationship between the two devices and uses at least one of the ERIs of both devices to declare the relationship. For example, you could query CDP to find out the neighbors of the device. The response would say A, B, and C, are connected to me (D). But instead of using A, B, C, and D, it would identify A, B, C, and D by their ERI.
Manual mapping is also possible, but more, well, manual.
When I was at LM, I made some learning bytes that explain how this all works. It's a series of videos (not very well tied together in the support portal). Go to your LM >> Training >> Learning Bytes and look for: 1) Fetching Instances through Active Discovery, 2) Scripted Active Discovery Syntax, 3) Manual Topology Mapping
Were there other issues you were referring to that were introduced in 187?
Specifically, it seems when trying to export a saved Topology Map to a dashboard for reporting, the saved map is basically not reflective of what the dashboard appears under.
Add to the existing issues in 1.86 where moving items in the map is now basically impossible. Dynamic maps, even custom-made ones, just reset mere moments after the devices are moved, and reset whenever any property of any single device is changed.
For example, selecting “network” devices on an edge device, say a Floor Switch in HQ which is attached to the main switch to show its connected devices, will reset the entire map to a default, or randomized, dynamic map.
Essentially it either takes the way that LM displays the Topology in one of its default settings or nothing.
This wasn’t the case before, as we were once able to edit the placement of devices under Hierarchal modes and dynamic modes alike in order to better represent the network topology.
After 1.85 Hierarchal maps are no longer editable, and from that point forward we’ve been unable to build a legible topology map of our core network.
From our Support Docs…
Topology Mapping Overview | LogicMonitor
https://www.logicmonitor.com/support/forecasting/topology-mapping/topology-mapping-overview
LogicMonitor’s topology mapping capabilities are focused on layer 2 and layer 3 mapping. Specifically, the LogicMonitor platform leverages Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) to dynamically generate network topology maps that show how data flows among the many resources (switches, hosts, firewalls, routers, and other network components) in your environment.
My understanding is that we support building maps out based on LLDP and CDP data. I’ve asked the TopologySource SME to confirm. We actually can get a lot more when these protocols are enabled. Often, users will disable them for security reasons.
Were there other issues you were referring to that were introduced in 187?
Not sure how else I can help here.
Bumping this again as, once more, the latest 1.87 UI Update has actually managed to worsen the situation.
Unsure if
This is basically what you need for the configsource for CDP, but I can see why they didn’t do it. The problem is IP address reusage. This toposource outputs the mac address of the queried device as the “from” node and outputs the IP addresses of its neighbors as the “to” nodes. The problem is that the IP address needs to be an ERI on the neighbor in LM. So, an ERI source would have to go along with this to make the IP addresses into ERIs on the device. At that point you run the risk of ERI collision/merging issues if IP addresses are reused somewhere else in the network. I suppose topo.namespace would be the way to mitigate this. Basically each customer (for MSPs) would have to have a namespace, then each IP network would have to have a sub-namespace (combination of the customer namespace and the network’s namespace).
import com.santaba.agent.groovyapi.snmp.Snmp
import groovy.json.*
Oid = "1.3.6.1.4.1.9.9.23.1.2.1.1"
wildvalueTerms = 2
def host = hostProps.get('system.hostname')
def props = hostProps.toProperties()
int timeout = 10000 // 10 sec timeout.
def eris = hostProps.get('predef.externalResourceID')
eri = eris.tokenize(",")[0]
eri = eri.split("::")[-1]
def snmpMapToTable(snmpmap, int wildvalueTerms = 1) {
rows = [:]
snmpmap.each {k,v ->
splits = k.tokenize(".")
col = splits.dropRight(wildvalueTerms).join(".")
wildvalue = splits.takeRight(wildvalueTerms).join(".")
if (!(rows.containsKey(wildvalue))) { rows[wildvalue] = [:] }
rows[wildvalue][col] = v
}
return rows
}
try {walkResult = Snmp.walkAsMap(host, Oid, props, timeout)}
catch (Exception e) {println(e);return 1}
try {entryRaw = snmpMapToTable(walkResult, wildvalueTerms)}
catch (Exception e) {println(e);return 2}
output = ["edges": entryRaw.collect{k,v-> ["type": "Network", "from": eri, "to": v["4"].tokenize(":").collect{address -> Integer.parseInt(address, 16)}.join(".")]}]
println(new JsonBuilder(output).toPrettyString())
return 0
I’d be happy if topology mapping would just utilize LLDP/CDP as a starting point. It’d be better & more accurate than what’s currently happening.
Wait, it’s not already doing that? Well, I guess I’m going to be looking into 1.3.6.1.4.1.9.9.23.1.2.1.1 & 1.0.8802.1.1.2.1.1.6.1 next.
Doesn’t seem to be, I routinely see switches that are 2+ hops down the chain shown directly attached to upstream distribution routers. Also routinely see switches shown attached to other switches in entirely different distribution segments.
Pretty sure 99% of the topology mapping problems would be resolved if LLDP/CDP were used as the primary source of truth on how devices are interconnected, then routing relationships and other methods used to add further context.
I’d be happy if topology mapping would just utilize LLDP/CDP as a starting point. It’d be better & more accurate than what’s currently happening.
Wait, it’s not already doing that? Well, I guess I’m going to be looking into 1.3.6.1.4.1.9.9.23.1.2.1.1 & 1.0.8802.1.1.2.1.1.6.1 next.