Meraki

cburtbcit · ‎Mar 5 2018

In my case, I have a service provider telling me one thing, a user base telling me another, and equipment that isn't say much of anything other than there was an outage. So I think your suggestion would solve a lot of problems. I think it would be nice if the status graphs (the green bars with info on mouseover) could be updated to show that the device in question was rebooted as well, and wasn't simply disconnected. It's great to see a graph of availability, but it's just pretty colors if you have to comb through the event log for any real detail.

cburtbcit · ‎Mar 5 2018

@PhilipDAth that certainly seems like an obvious feature to add. I found it amusing that I bragged to myself about how easy it would be to figure this out, just to find that the error log is chock full of information I may never use, and is missing this seemingly-critical piece of information. I would add to your suggestion that at 15 or 30 minute intervals, there should be a general status log entry that includes the uptime, the number of errors since the last status entry, and perhaps avg. bandwidth utilization over the interval.

cburtbcit · ‎Mar 5 2018

Thanks for the reply. All I see in the event log is a gap in the events during the outage I'm investigating. I don't know if that gap exists because the device was unable to send log data to the cloud due to a connectivity problem, or if it's because the device wasn't powered on to log data. I will follow your advice and contact support to get the up-time.

cburtbcit · ‎Mar 5 2018

Does anyone know of a way to determine if an MX appliance went offline due to losing power versus losing connectivity? The event log doesn't seem to contain a "boot" event, only primary uplink status change. Presumably, this event won't show up in the log if there's no secondary link to transmit it.

cburtbcit · ‎Sep 6 2017

TL;DR Be sure you've got trunking enabled on the switch! It appears as though I solved my own problem! The switch ports were *not* configured as trunks as I had thought. When clearing the configuration of the interfaces, I had run the appropriate "switchport mode trunk" command but somehow, it didn't stick. As a result, none of the VLAN tagging was working. Hence the error message in my original post. Effectively, the "trunks" were configured as access ports on VLAN 1.

cburtbcit · ‎Sep 6 2017

We've recently deployed several MR33 APs. We did some pretty extensive testing beforehand, so we were confident that all we had to do was connect them to a trunk port, and then specify the management VLAN in the settings for each AP. My trouble is that the last three APs I deployed, despite connecting them to our switches the same was as the previous three, will not get a DHCP lease from the AP management VLAN. I continue to get the error message that the AP is getting its IP from VLAN 0 instead of the configured VLAN 1. This message doesn't make much sense because I *did not set* the VLAN to 1, I set it VLAN 610. Anyone else run into this?

Meraki

Community

About cburtbcit

cburtbcit

Community Record

Badges

Re: MX Firewall - Lost connectivity vs. lost power?

Re: MX Firewall - Lost connectivity vs. lost power?

Re: MX Firewall - Lost connectivity vs. lost power?

MX Firewall - Lost connectivity vs. lost power?

Re: MR33 AP won't obtain DHCP lease from correct VLAN

MR33 AP won't obtain DHCP lease from correct VLAN

Re: MR33 AP won't obtain DHCP lease from correct VLAN

Re: MX Firewall - Lost connectivity vs. lost power?