About MRCUR

MRCUR · ‎02-29-2020

Late to the party on this, but a big FINALLY to the MV team for adding this feature!

MRCUR · ‎02-20-2020

@EvanM Yes, we still run the two vMX appliances that I referenced earlier. Current costs are in line with what I posted previously. They just work for us which has been great. Essentially no maintenance other than updating the Azure VPN subnet list when we've added additional subnets at other sites.

MRCUR · ‎02-12-2020

Thanks @Kevin_C. Great to see that's supported now.

MRCUR · ‎02-07-2020

Any update on full disk access profiles that @Baustinceltic asked about @Noah_Salzman?

MRCUR · ‎07-24-2019

@aws_architect No sorry, we don't use wired 802.1x anywhere currently.

MRCUR · ‎04-26-2019

@Chriz_J I'm not sure what you mean by "emergency" management IP. If you set an IP through Dashboard or the local UI for a switch, that is the IP the switch will use for its Dashboard (Internet) connection. There isn't a concept of a "backup" or "emergency" IP on Meraki devices (they will automatically revert to a previous IP however if you incorrectly configure the management IP).

MRCUR · ‎04-25-2019

@BlakeRichardson wrote: @SoCalRacer Could you not mount on the ceiling tile itself? Sandwich the tile between the camera and a piece of wooden board on the otherside so that it has a decent fixing. Much easier to replace the tile than the T-bar when you end up replacing hardware. The MV12's are so light there isn't really a need to have a wooden bar above the tile. We screw directly into the tile with the plastic screw retainers (for drywall) above the tile to keep the screws secure. We're over 1,000 deployed now and none have come off tiles unless encouraged by flying objects.

MRCUR · ‎03-06-2019

This is a known issue which I believe affects all models of cameras. Engineering thought it was fixed on 3.26 firmware but it's still happening.

MRCUR · ‎02-15-2019

@MRCUR wrote: @Mosquitar wrote: Hi, Did you ever get this issue resolved? If so, what was the fix as we are experiencing issues with a topology similar to yours. Thanks Unfortunately not. I had to reopen the support case today as the issue (likely with DNS) is still occurring and causing instability for the 425 stack. The school year ended before we were able to determine a root cause last year so hopefully it can be found this time around. The remaining issue is being caused by malformed DNS packets through the app X-VPN - https://xvpn.io/. The individual packets are significantly larger than would be expected for a DNS response and are possibly all being sent to the MS425 CPU to process for DNS inspection. We've put in place ACL's on the 425 stack temporarily to block all DNS traffic that does not go to or come from our internal DNS servers. MS engineering is looking into the issue.

MRCUR · ‎02-14-2019

@Mosquitar wrote: Hi, Did you ever get this issue resolved? If so, what was the fix as we are experiencing issues with a topology similar to yours. Thanks Unfortunately not. I had to reopen the support case today as the issue (likely with DNS) is still occurring and causing instability for the 425 stack. The school year ended before we were able to determine a root cause last year so hopefully it can be found this time around.

MRCUR · ‎11-13-2018

I'm pretty sure you'll need to NAT to a different IP for the WAN 2 rule. Can you go for the other option @PhilipDAth presented so this isn't an issue?

MRCUR · ‎11-12-2018

Are you unable to use a Virtual IP in this scenario and just connect WAN 1 port on each MX? This would allow you to leave the NAT rules alone.

MRCUR · ‎11-08-2018

As long as you have a route to the camera VLAN, you'll be okay.

MRCUR · ‎11-02-2018

@Asavoy We have lots of MR34's on 25.12 but the only SSID with WPA2 uses Meraki DHCP (which is working).

MRCUR · ‎11-01-2018

@CHAadmin I don't disagree with your FR at all, but GCDS is not "messy". It's pretty simple to setup, requires very little management once implemented (unless you make AD changes) and can easily allow for single identity management in AD.

MRCUR · ‎10-27-2018

Ask for some pizza while you're at it.

MRCUR · ‎10-26-2018

@capricorn80 wrote: If a machine is not talking 802.1x the how can you use certificate? This is for devices like chromecast, amazon sticks etc. Also Meraki is not support both MAB and 802.1x with same SSID. MAC auth can work well for those types of devices if you don't want to do PEAP with them.

MRCUR · ‎10-24-2018

See here for my current Azure costs: https://community.meraki.com/t5/Security-SD-WAN/TCO-for-vMX100-in-Azure/m-p/30075

MRCUR · ‎10-24-2018

You're absolutely right that this is a limitation of the MV platform today and certainly a problem for some deployments as you described. The MV platform today uses HLS for streaming which has a delay because of how it sends chunks of content to clients. This is a good explanation of how HLS works and why it has a lot of latency: https://www.theoplayer.com/blog/low-latency-hls-lhls Switching to a different streaming protocol is not an overnight task for the MV team. I know @GeorgeB is aware of the requests for lower latency streaming and I'm sure it's on his to-do list for the team.

MRCUR · ‎10-17-2018

We use an EA agreement with a yearly monetary commitment. The vMX we run in East US I did a reserved instance for the VM portion so we just pay for the OS disk and public IP each month on that.

MRCUR · ‎10-17-2018

I've had much better luck with MS devices when the management VLAN is not the native VLAN on the uplink interface(s). MS devices like to tag their management traffic all the time which can cause issues when the native VLAN is the management VLAN.

MRCUR · ‎10-17-2018

We run two vMX's in Azure today. One is in East US and the other is in West US. Looking at last month for the West US location, here are the costs. We transferred 10.3TB of data through this vMX over the last 30 days according to Dashboard. vMX disk: $1.86 vMX VM (D2 v2 - set by Meraki): $108.49 Public IP: $2.89

MRCUR · ‎10-17-2018

@nikiwaibel While I understand what you're going for, badgering Support about this isn't going to change anything right now. Make sure your sales team knows you want IPv6 support in the MX line so they can add your account ($$$) to the feature request.

MRCUR · ‎10-16-2018

Is your MX meant to be your 3750's default gateway at 192.168.76.254 or is this another device?

MRCUR · ‎10-12-2018

Unfortunately @MacuserJim is correct. The timeout is a global org setting so the users will need to keep the session active. If you have video walls set up, you could use the new auto rotate walls option to have the page auto refresh and move between walls. This should keep the session alive although I have not tested it since the feature just launched (hopefully it's available for everyone!).

MRCUR

Community Record

Badges