Every wireless dashboard user just woke up today with an upgrade in their dashboard this morning. For more, you can take a look at the blog here, or for detailed explanation, take a look at the new documentation page.
We know that across the IT industry, folks are challenged with multiple dashboards, troublesome wireless clients, network & management complexity, and difficulty troubleshooting the network end-to-end. Our goal is to make the user experience seamless, reduce troubleshooting from hours to minutes, and ideally make it proactive instead of reactive.
To summarize the updates:
Happy for you to post your feedback! Thanks.
I'm seeing the same as Nolan: AP -> first switch, then nothing afterward.
However I do like this very much, especially for initial helpdesk troubleshooting when "the wireless doesn't work".
That's a great step forward!
Request : for the switchlinks would it also be possible to include the link bandwidth usage and packet drops due to QoS? Qos queue status etc...
I also experience the bug where only the first switch is displayed:
Behind the switch shown there is another MS225 acting as L3 switch, and behind that a pair of MX84's.
Thanks for pointing that out @GIdenJoe
You likely have a corner case scenario, as it should be showing the end-to-end view. I've notified the engineering/product teams about this.
We have the same, only the first switch is shown. The client below has an MX pair as the next hop. The network is combined and includes the MR, MS and MX
After looking through two networks and fifteen clients I found one that has more than one hop, note this site has the MXs in a separate network.
Here is the topology diagram for the network that doesn't show the MX:
The route for all data traffic is via the MX pair at the bottom that show the STP disabled redundant links, but not the actual live ones. The diamond at the top labelled MX is the DHCP server that is actually on a different Meraki network and only used for DHCP and the management VLAN. The diamond at the left doesn't exist (perhaps it is the live MX links) and the Cisco IOS switches that predated the MS stack is also on the topology as shown.
I think if the topology was correct, then the new troubleshooting would flow properly...
Anything is possible! We analyze our "Make A Wish" submissions as well, and I've seen that request a few times.
In my network consisting of MR45 Ap's the client troubleshooting always shows incorrect chain - client connected to AP and this AP connected then to another. In real all AP are connected to 3rd party switch/router (no LLDP enabled).
It looks like that:
Nope, bot are connected to wired network.
When looking at client connected to the other AP it looks exactly the same but with reverse order of APs.