May 4 11:05 – May 4 12:28
Very high proportion of CRC errors
Very high rate of packet fragments
Surely this condition is worthy of an alert. I just happened to be in the dashboard and noticed a switch port was red. Or am I meant to log into the dashboard and visit every switch in every network in every org on a regular basis?
I've thought the same. Every time I've encountered one it's been stumbling into it.
The problem with this style of error is it comes and goes (usually based on load on the port).
You would get a lot of alert emails if there was such an option.
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.
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.
Just wanted to step in and quickly introduce myself as a member of the MS Product Management team. We hear you, thank you for the candid feedback! Absolutely understand the need for email alerts for issues such as CRC errors that can cause network performance issues.
Serviceability and logging improvements is a major focus area for us. Over the last year, you might have noticed several improvements in this area. Some examples below:
- Native VLAN mismatch detection
- STP Anomaly detection
- UDLD alerts
- Critical temperature alerts
While I don't have an ETA to share with you today, I do want to clarify that CRC error alerting is on our list. We can connect over DM if you've any questions I could help answer.
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?