Unfortunately, Seeing Isn’t Always Believing With Meraki Network Topology View (updated)

 After opening a support case, Meraki was able to verify what I describe below in their own lab testing- some MX ports were not doing LLDP right. And…. the fix: “The issue of the transmission of LLDP packets from the MX is fixed in versions starting MX14.2” – which so far is proving to be the case. (Now we need to solve client MAC addresses showing up on the wrong switch ports, but that’s another tale for another time.) Read on if you’d like, but keep in mind that they DID fix this problem at long last.

---

The only thing worse than an important feature that’s missing in a network management solution is an important feature that works wrong. Those of us who pay for these systems expect the features that we trade our dollars for to actually, well, work. And bad information is just terrible in that it sends us down time-wasting bad roads.

Meraki- you have a problem. Your topology view doesn’t refresh for hours, days, or weeks after changes are made. And for whatever reason, you have not given us decent LLDP tools that we can invoke on demand. That’s the polite description, which can be abbreviated down to your topology view sucks at times.

Before I show and tell my latest frustration in this regard, let me share Meraki’s summary on it’s topology view and evidence that what I’m about to describe is not my frustration alone. See this post from the Meraki community. Now on to the defective topology feature.

It Just NEVER Updates

In a faraway branch location, we had two switches that daisy-chained off of another switch due to physical layer constraints. Here’s the old topology:

Pay attention to VillaRosa-3, Villino-1,and Vilillino-2. V1 and V2 were daisy-chained off of V3. THEN THEY WERE MOVED TO EACH DIRECTLY CONNECT TO THE MX. And then I got an email… “The switches got moved to ports 6 and 7 on The MX, but the topology isn’t updating. Maybe I should restart the devices…” As we see in the community forums, we may be waiting quite a while for this map to update…

The Implications

Few things are more basic in network support than simply knowing what connects to what- both physically and logically. Commands like <show cdp neighbors> and <show lldp neighbors> are pretty important, but not available in the Meraki dashboard paradigm. Instead, we need to rely on incomplete or inaccurate graphical information.

As I mentioned above, V1 and V2 moved to direct connects on the MX. So what does the MX say about the switches that are connected to it? Unfortunately, nothing. For whatever reason, Meraki has never seen it as important to give full lldp information for devices connected to an MX:

This is utterly nonsensical for enterprise-grade networking equipment. But it gets worse. Let’s look at one of the switches that has had it’s uplink moved to the MX. Days after the move, the switch still says it’s connected to it’s old uplinked V3 switch:

This is pretty bad. It’s wrong, it’s outdated, it’s misleading, and it’s inexcusable. Let’s have a look at “VillaRosa-3 / 51.

To recap:

• Topology views don’t refresh as they should (if ever)
• The MX doesn’t tell who it’s lldp neighbors are- which is a glaring deficiency
• The lldp neighbors information on the Meraki switches can’t be trusted
• There are no obvious ways to invoke on-demand refreshes for topology and lldp views, we are at the mercy of some undeclared loooooooong refresh timer

That this “feature set” can be this off-kilter defies logic- especially when you consider the cost of the gear and it’s licensing and the importance of lldp to network support.