Perhaps you should make a wish.  Oh, wait..lol.  ... View more

That's nice if you have 2 WANs to work with.  ... View more

It's hard for me to believe that it's a "major focus area" for you when you've only manged to introduce 4 minor features over the span of a year....10 years? into the life of the product.    I still can't get alerts for high CRC and packet loss...or high latency...a year after I first pointed out this glaring oversight/design flaw.   My users still have to call me and tell me about these issues.    Then I have to explain to them why the super expensive fancy security appliance I advised them to purchase/sold them is so expensive if it can't send a simple alert on something so basic.    If you can detect Native VLAN mismatch and STP Anomalies...why can't we get alerts?  If you can detect high CRC and packet loss and high latency...why can't I get an alert?  I'm sure it's not because you can't do it or because it's too hard.  It's either A> a very low priority or B> something you've decided not to do for some reason.     Oh yeah...I still can't see any type of log entry AT ALL for Layer 7 Deny.  That makes troubleshooting connection issues caused by layer 7 rules real easy.  Brought this up with years ago and got a call from someone on the UI team that seemed to have no concept of the difference between Layer 3 and Layer 7 FW.    Meraki is sooooo nice, until you run into these bone-headed, painfully obvious, shortcomings, and you're like, WTF?  ... View more

Over a year goes by and Cisco can't even be bothered to respond, much less implement this incredibly useful, very simple request.  The arrogance is unreal.  ... View more

And network saturation shouldn't be that difficult either.  I already input the maximum bandwidth for each WAN on the traffic shaping page (A).  The MX already records and reports on real-time (or near-time) usage (B).   If B >= (A - X) for more than Y mins, then send alert.     Let me pick X and Y.     "Wide use case" for any alert is easily accomplished by letting the admin pick the threshold/s.  But I'm sure the devs at Meraki can/already have figured this out.  Whey they refuse to do so is a never ending source of Meraki hate for me.    Phillip, you had the same concern when I complained about this same lack of alerting for high-CRC and packet loss, last year.  Again, it's already reported on in the switch page of dashboard.  The simple, obvious solution is the same.   Thresholds.    They even have thresholds already defined for CRC and packet loss that light up with different colors in the dashboard, but no option to get an alert for this common network condition either.  F***ing pathetic!    Why?  Seriously, this sh*t is so aggravating.  We pay WAY too much for this kind of half-baked design and lack of any real/meaningful response from Cisco.   https://community.meraki.com/t5/Dashboard-Administration/hard-to-imagine-why-there-isn-t-an-alert-for-high-CRC-and-packet/m-p/18655   I've seriously come to conclude that Cisco is simply being stingy with data.  Alerts cost money.  Probably fractions of a penny, but they add up.  Why wouldn't Cisco be motivated to restrict and limit alerts at every opportunity.  Why would they give us any choice in the matter.   It's not like they haven't thought about something as basic as network health alerts...then again?  ... View more

Yeah, it's not rocket science.  They obviously collect the data.  Implement a threshold and add it to the alert page.  I'm sure the devs at Meraki can figure it out.    Even on a network where I have the overpriced Meraki Insight add-on, I still can't get a simple alert for this incredibly common problem.    What really boggles my mind is that I have to even ask for this seemingly basic alerting function for a common network issue...and I'll probably be ignored (or patronized and told to submit a wish) and never get it.  None of my wishes ever come true.  Even for the most simple, obvious, no brainer tweeks or additions.    I love a lot of things about Meraki, but things like this really piss me off and make me wonder WTF is going on in the design meetings.   When I say I have a "love/hate" relationship with Meraki, this is exactly the type of thing I'm thinking of when I think about all the hate.    I don't want to have to learn how to query the API just to get bare bones basic alerting on a very common network issue.  I have a million other things on my plate, like most of us do.  ... View more

I'm actually amazed it took this long to get some training programs in place. The roll-out has seemed very haphazard/disorganized/half-a**ed. And why are the classes sizes so limited anyway? It's virtual. Your Cisco. I'm sure you could easily expand the class size if you wanted. What gives? I'd make a wish, but my wishes never come true. ... View more

@EliseK, I don't see a form on this page, no matter which date I click on. Just blank white space to the right on the dates. I'd paste a screenshot if I could. I've tried this in Chrome and Safari. https://meraki.cisco.com/webinars/signup/2690/ecms1%3A-north-america-sessions/.   Update: I tried from another computer and it's working, so something wrong locally. ... View more

Also, I really hope I'm not going to have to travel 1000+ miles just to take EMS2. Please add more cities for those of us that aren't lucky enough to live in (or near) one of the 3 most expensive cities on the planet. San Francisco, London or Sydney are the only 3 cities listed on the Interest form. Better yet, add a virtual option. I can't imagine anything that couldn't be covered virtually. We are talking about cloud managed networking gear, right? ... View more

I'd love to be able to register for EMS1. No mater which date/time I click on, there is no form displayed. I've tried this in Chrome and Safari. Does this mean the sessions are full? A note to that effect would be nice. ... View more

No, but that's an annoying and possibly related design flaw too.  I was refreshing the page but also watching packets get denied in syslog for 10 mins after the change. It actually took that long for the change to be processed.  ... View more

Yeah, I found that thread too.  At least they're consistent...kind of.     In my experience, DNS lookup failures are a pretty rare event (and short-lived).  But, even if that happened, the MX still records logs locally.  I wouldn't necessarily lose any logs at all if the problem was quickly corrected, which it likely would be do to the obvious impact on the rest of the network.   Personally,  I'd prefer to afford myself of all the features I get by using a FQDN (load balancing, fail-over, etc.) vs. being forced to use an IP address just in case, maybe one day, DNS lookups fail for a short time and my logs are only recorded locally on the MX instead of being exported.      ... View more

I'd love to hear someone from Meraki explain the rational behind this limitation, if any.    FYI, there are plenty of legitimate reasons for a log management service provider to use FQDN vs. IP (load balancing, fail-over, etc.)   "The important thing about DNS is that it provides more than just A records (hostname = IP). DNS provides different types of records such as MX, CNAME, TXT, etc... that may be required by some software, sometimes. It allows multiple address records, IPv4 + IPv6 records, dynamic addresses, load balancing, geo location based resolution, fail-over/redundancy, etc... DNS tells you what things are (www.google.com is google's web service, 172.217.4.110? What's that?) It allows you to change these settings/records and have them picked up by clients without making changes on all the clients. DNS can do complex things. There's often a clear advantage to using DNS over a direct IP address. FQDNs can be a requirement Some things like web servers that use name based virtual hosting or load balancers, etc... absolutely require that you address them via an FQDN or hostname. They determine how to respond to your request based on the FQDN that you are connecting to. Connecting via an IP may not work at all. SSL certificates are issued based on domain names, so you may not be able to use some SSL enabled services (properly) without DNS."   https://serverfault.com/questions/788862/why-should-i-use-an-fqdn-instead-of-the-servers-ip-address     ... View more

So...if I use a FQDN and there is a DNS service failure (rare event), I won't get any log entries.  But since I'm forced to use a single IP address, if my log management service decides to change the IP address of a server for some reason, guess what?  I won't get any log entries.  So, no, I don't think that's a good reason.  At the very least, allow me to make that decision and put a little warning in the help bubble.  ... View more

It's an error condition that most likely coincides with diminished network performance.   It indicates some sort of problem that needs to be fixed.  In fact, Cisco obviously agrees, this is why they do currently alert on the condition (in the dashboard only).   High CRC errors could be caused by excessive network load, which is also a problem that would need to be addressed.  In my case, it was just a bad cable connection (loose patch cable connection; reseating fixed it).   Email alerts could be easily tamed with a simple threshold.  In fact, Cisco has already implemented the threshold.  That's why my error showed "very high" CRC errors and colored the port red.  They also have a "high" range (orange) and a "medium" range (yellow) (as I recall, the error is gone now after reseating cable).   Simple solution.  Send email alert when there are "high" or "very high" CRC errors for more than X mins.  I'm basically asking them to add one additional action.  When you make the port turn orange or red, go ahead and send me an email so that I might actually notice it and take action.     ... View more