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