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

update 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.

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

  1. Daryl

    Lldp and cdp are considered security vulnerabilities. Any firewall propagating cdp or lldp would cut against the notion that a security device be secure. Name one vendor’s firewall who sends such information.

    1. wirednot Post author

      Thanks for reading and for commenting. I get that on the firewall to a point. But that is the least significant part of what isn’t happening here, IMO.

    2. Andrew Webster

      Just to point out that CDP and LLDP are layer 2 protocols, not sure where the firewall issue comes into play. LLDP and CDP don’t propagate past a routing boundary. Your layer 2 shouldn’t be exposed to where the bad guys plays, ie: turn it off facing Internet, otherwise it is a must-have tool for network admins.
      I have my own issues with Meraki, but that’s a story for another day.

      1. wirednot Post author

        Thanks for your perspective, Andrew. I did just look in on our big Juniper Enterprise firewalls. FWIW they absolutely support LLDP, as well.


    However you can run an API call anytime you want to get the cdp/lldp information that you are complaining is missing.

    1. wirednot Post author

      Sure. But… when you have branch sites with no real API-skilled IT folks, that doesn’t work. If the API is supposed to be the go to, then it should be stripped from GUI so bad info is not showing.

  3. kili

    Did you open a support case in order to see if any known bug or configuration issue is in your environment? What was the feedback of the support-team?

    Regarding API: You don’t need any skilled person on site for this. As it seems like you are doing most of the monitoring also from somewhere else right? So you can let the API call run beforehand and see if there is different information than in the topology GUI.

    Overall I agree that the page should update and represent the state as it is at least after a few minutes after rewiring.

  4. Chris Russo

    Meraki sucks for large enterprise networks. Very bizarre implementation of OSPF, no advanced BGP features (that I can find), and next to zero granular troubleshooting tools, i.e, no debugs or CLI available. Meraki MX Security appliances pale in comparison to any NGFW, no zones, no true appID equivalent. The wireless side seems to be it’s only strong point. Ultimately, Meraki seems like a solution designed more for system admins than real network engineers.


Tell me what YOU think.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s