Or the SD-WAN Plus licence now that MI is EOL ... View more

Most definitely,  I alert on: - WAN(n) latency > (n)ms for (n)minutes or more in a (n)minute window - WAN(n) packet loss > (n)% for (n)minutes or more in a (n)minute window - WAN(n) status changes - WAN(n) usage > (n)Mbps for (n)minutes or more     ... View more

Will do, thanks Ryan ... View more

The only part I am finding useful is the Overview page and then clicking on the Wireless under clients:     The Association section then reveals some interesting Failure types that I have not seen anywhere else: I don't seem to be able to find any explanation of what would cause these errors anywhere - at least its more info that was previously available that I can see.   ... View more

I encountered a similar situation recently. Given there was a LAN connection between the 2 buildings and there was no technical reason for them to be separate, I merged into a single LAN (with VLANs etc where necessary), which allowed me to put an MX95 in each building and configure HA. Don't get me wrong, it wasn't a simple task and required some detailed planning, but in essence that's what I did. Is this an approach you could take and get 2 MX's of the same model to give you the redundancy you need?   If you kept existing subnets then you could even route each building over its existing ISP but have the backup of the ISP connection in the other building. ... View more

Thanks Ryan, I had guessed as much but good to have it confirmed.   ... View more

@Ryan_Miles Is there anything you can do to get some traction on this or at least point us to someone in Meraki that we should raise this with?   ... View more

I think its much simpler than that.  It is clearly stating that the packet has been ALLOWED onto our LANs when we know that we have configured IDP to block these. The report has to show that the packet has been dropped otherwise we keep getting it in the ear every day asking why our Meraki firewalls are not blocking malicious packets (when Meraki support tell us the opposite to what is inferred by the Security Center). Its even getting to the stage now where I am being challenged why we are using Meraki MX's when this is happening!! ... View more

I don't understand why someone at Meraki cannot understand why saying packets are ALLOWED when they are not thinks this is acceptable.  Do they not understand how we have to explain this to Security people who keep asking why malicious packets are being allowed onto our LAN's. Maybe we should start logging cases daily until this is fixed 🙂 This issue needs to be brought to the attention of someone like the MX product manager or someone similar. ... View more

I agree 100%, showing ALLOWED is just plain wrong. ... View more

So it does, thanks for that @jimmyt234  Could you please PM me when Meraki make you aware of a fix? Many thanks ... View more

Try fullscreen in the Vision Portal again and just leave it, I can assure you it ignores the timeout setting.  Downside of the Apple box is no SSO at present. Do every solution is really a compromise. ... View more

Your other option is to use the Vision Portal in full screen mode,  this bypasses the global timeout setting. However the issue I ran into on a decent Windows PC displaying a 6 camera videowall was the PC running out of resources and hanging very regularly. Since replacing with the AppleTV box no issues. whatsoever. ... View more

If all they want is to view images then we got round this in the end by using Meraki Display on the AppleTV box.   Only downside is SAML isn't supported yet. ... View more

Yeah, that's what support told me.  Our MX is overworked (but we have no visibility of that) - I think mainly due to having group policies on some VLANs that whitelist URL's so its constantly logging blocked ones. Even so, displaying "Allowed" is just plain wrong - had our Risk/Security Dept running around asking why IDS had permitted malicious traffic into our network. - Imagine trying to explain that for that particular MX the "Allowed" is incorrect when all the other MX's show "Blocked".   ... View more

The worrying part is where against some MX's it says "Allowed" but when you speak to support they say no it hasnt!   Really needs to report correctly in the dashboard as its incorrect saying 'Allowed'. ... View more

193.177.182.40 149.50.116.115 185.224.128.74 ... View more

All our MX's being hit too, diff src IP's though. ... View more

@Ryan_Miles Just thought I would let you know that we have gotten multi-VLAN mesh working between a pair of MR76's.  Thank you so much for your help and guidance on this. ... View more

I am seeing the same hitting my MX's.  They all show as BLOCKED in the MX Events tab apart from one site where it shows ALLOWED with the exact same settings. The reply I got from support was:   "The indication "Allowed" on this alert does not imply that the attempted injection/overflow is accepted. Due to out-of-band packet processing, the MX could not locate the individual packet during this processing hence why it labelled it as allowed even though it was still blocked. This occurs due to high memory constraints/load on an MX, where I can see on the backend that the load on this MX is over the threshold where it will have to stop certain processes to wait for a free CPU cycle to run processes."   I have since raised feedback asking for MX memory/CPU load to be visible in the dashboard.  Given that support can see it at the backend I see no reason why it shouldnt be available in the dashboard as it could assist with capacity planning. ... View more

I think I've got it.  Will find out when the kits on my desk and I'm pulling my hair out. Thanks Ryan, really appreciate your guidance on this one  ... View more