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