Meraki

GreenMan · ‎Dec 21 2020

You mentioned vMX in your Title; you can't run MI on vMX. Remember that MI works by sitting on the boundary between the HTTP client's LAN and that site's WAN link. The vMX sits at the opposite end of the HTTP connection - adjacent to the server. See "Where should I enable Meraki Insight?" here: https://documentation.meraki.com/MI/Meraki_Insight_Introduction

GreenMan · ‎Dec 21 2020

Using Network Objects may help you: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Network_Objects_Configuration_Guide

GreenMan · ‎Dec 21 2020

From where I'm sat, I see no particular issue with N255. I suggest you raise a Support case.

GreenMan · ‎Dec 18 2020

You can configure your MV cameras to retain motion only for a specific day/time, such as your example. In that case you would configure both a schedule for retention and enable motion based retention. Note that exporting is different from retaining. Export is usually a manual operation, based upon finding the clip you are interested in - but you can only export it, if you first retain it!

GreenMan · ‎Dec 18 2020

Are you able to capture details of the API call that Orion is making towards the Dashboard? Have you been able to verify that the API key(s) you've tried are working, outside of Orion - perhaps by using Postman? If you are to do both of these, try using the call Orion is making, within Postman?

GreenMan · ‎Dec 18 2020

As API is based around the Administrator - which can be for multiple Orgs, some in and some out of compliance, so I would agree this should work. Did you try using the v1 endpoint? https://developer.cisco.com/meraki/api-v1/#!get-organizations Bear in mind that v0 was deprecated in August, so a backwardly-compatible fix may not be implemented, particularly if the v1 call works.

GreenMan · ‎Dec 17 2020

I guess I'd ask the question Why are the other 3 APs on a different VLAN? It's unlikely to be because of scaling concerns, I'd have thought. With so few APs, it's unlikely to be because you have thousands of clients, all on the same broadcast domain... If those three APs are geographically separate, they'd have to have overlapping WiFi cells between the two locations, to take advantage of any roaming anyway. I like the Meraki 'keep it simple' approach, extended to config here: only L3 roam if you have to. Assign all clients in one SSID into the same VLAN, on a site (any given Network) if you can.

GreenMan · ‎Dec 17 2020

If you have an MX with built-in PoE ports (MX65 or 68), you can use one of those two ports to power the MG, then connect the other MG port to that MXs WAN/Internet port. You would want to configure the MX PoE port to prevent traffic flow over it. It's not ideal, but it will work.

GreenMan · ‎Dec 17 2020

Meraki generally, and MX specifically for this, are pretty agnostic towards the underlying network over which they communicate. The key questions to ask are: How can my Meraki devices connect to the network? In most cases we're generally talking RJ-45 ethernet, though other form factors, such as ethernet over fibre could well be applicable, for more powerful MX models. How is your VPLS presented? Will my underlying network carry IP traffic? (VPLS is, I think, agnostic as to the layer-3 you use; you probably wouldn't, but you could, theoretically use IPX over it too!?) Can my Meraki devices access the Internet over it? Meraki is a cloud service, you need to be able to reach all the necessary cloud resources. For VPLS that would probably mean - does one or more of my sites have an Internet break-out and how do I ensure my meraki devices can reach it? That probably means some routing between your VPLS termination and a perimeter firewall (which will need the right rules). 'Internet' also includes access to public DNS, to resolve Meraki domains and similar. Hope this helps

GreenMan · ‎Dec 14 2020

No, this is not supported. As your RADIUS server is there to be the centralised point of authority, I'm not sure why you would want to do that anyway...? Have you looked at iPSK without RADIUS? https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_Authentication_Without_RADIUS

GreenMan · ‎Nov 26 2020

They will probably work (Meraki don't deliberately stop non-Meraki SFPs from working) but they won't be supported by Meraki.

GreenMan · ‎Nov 25 2020

Apologies all - a plain typo; I meant that Mgig ports don’t support 10Base-T. They do support 10GBase-T, except some of the MS390 models, as pointed out. I think the ready-reckoner table I included got the details more accurate than my written summary 🙄

GreenMan · ‎Nov 25 2020

The following Meraki switches currently support MultiGig, in a variety of formats: Note the limited Mgig datarates on a couple of the MS390 models. Note too that the multigig ports do not support 10GBase-T. Gigabit ethernet ports, on currently shipping Meraki MS switches, all support 10/100/1000. All of these switches are really designed for the access layer, rather than server aggregation. They, as with other access switches, do not have very deep buffers, ultra-low-latency etc. that some server deployments rely on. In general, Cisco Nexus switches should be considered in Data Centres. MS350 MGig copper Gig copper MS350-24X 8 @ 100 Mbps - 10Gbps 16 MS355 MS355-24X 8 @ 100 Mbps - 10Gbps 16 MS355-24X2 24 @ 100 Mbps - 10Gbps NA MS355-48X 16 @ 100 Mbps - 10Gbps 32 MS355-48X2 24 @ 100 Mbps - 10Gbps 24 MS390 MS390-24UX 24 @ 100 Mbps - 10Gbps NA MS390-48UX 36 @ 100 Mbps - 2.5Gbps 12 @ 100 Mbps - 10Gbps NA MS390-48UX2 48 @ 100 Mbps - 5 Gbps NA

GreenMan · ‎Nov 25 2020

If you point Organization > Summary report at an appliance Network, right at the bottom right, you get summary uplink performance information for your selected timeframe (either Past month or Custom range might do what you need). The last variable is the uptime, as a %age, reported for the two WAN uplinks (assuming your MX has both connected).

GreenMan · ‎Nov 24 2020

I'm pretty sure that MX doesn't support CoA either - it would be different with an MS switch port...

GreenMan · ‎Nov 24 2020

When you select the client device in the Dashboard (under Network-wide > Clients), does it show your configured Group Policy as being applied to that device? (Bottom left, under 'Device policy:') Assuming so, have you checked for any permit rules which might apply to these flows and be applied before the Group Policy rules you have configured? as per: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Layer_3_and_7_Firewall_Processing_Order#Group_Policy_Behavior

GreenMan · ‎Nov 24 2020

No Meraki MV camera models incorporate mechanical Pan, Tilt or Zoom (PTZ) features, after installation. The camera lens can be spun basically through almost 360 degrees, but this is used by the installation engineer to orient the camera correctly once. It is then static. With MV22, of course, you can optically zoom in or out, but in that chosen direction only. If you require 360 degree coverage, look at the MV32 camera. Note that this is a fisheye camera, but allows 'Digital PTZ' - you can de-warp the fisheye view and 'look around' within the 360 degree field of view. https://documentation.meraki.com/MV/Viewing_Video/Viewing_Video_with_the_MV32

GreenMan · ‎Nov 24 2020

Is your setup configured to use Insight VoIP Health? https://documentation.meraki.com/MI/MI_VoIP_Health MXs use ICMP for this monitoring.

GreenMan · ‎Nov 24 2020

It's possible your MX still holds active sessions for those applications from the device in question, which are likely to be maintained. Have you tried disconnecting the device from the network for a period of time - or even just rebooting the MX - to clear?

GreenMan · ‎Nov 24 2020

As the MX64 (and other 'small') MXs are fanless, they use their metal body to help dissipate heat. The same goes for the small switches. Maybe fit a USB fan, as per this thread? https://community.meraki.com/t5/Security-SD-WAN/MX-Temperature/td-p/81273

GreenMan · ‎Nov 24 2020

You will want the Psk parameter within this call: https://developer.cisco.com/meraki/api-v1/#!update-network-wireless-ssid There are a number of threads, elsewhere in the community, with details of scripts to change PSKs (e.g. this one: https://community.meraki.com/t5/Wireless-LAN/Automated-password-for-Guest-wireless-user/m-p/67536#M10290 ) though it looks like they all use v0 of the API. These should still work, BTW, but it is recommended to transition to V1, for lots of great reasons: https://developer.cisco.com/meraki/api-v1/ Has anyone out there done this, yet? Bear in mind that, if you use a Template, with multiple Meraki WiFi Networks bound to it, changing the PSK once, in the Dashboard UI, will actually change it for all those Networks. https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates

GreenMan · ‎Nov 19 2020

I think there are quite a few developments in the pipeline. I strongly suspect that will be one of them (as will - my door has been open longer than x minutes) Meraki likes to get stuff out there early and then develop based upon the feedback received from our customers - so keep the wishes coming!

GreenMan · ‎Nov 19 2020

I'd be interested to hear why you'd want to do this? As soon as you take the clips out of Dashboard, you lose the motion recap facility, in particular, and it becomes much more difficult to find specific events - assuming you're looking for something specific in the footage, of course. If you're concerned over retention you can configure cameras to only retain footage which includes movement events https://documentation.meraki.com/MV/Initial_Configuration/Video_Retention. If that gives you insufficient timespan for past events - or you just need a more guaranteed retention time, then cloud archive is also available.

GreenMan · ‎Nov 17 2020

@PhilipDAth 's suggestion would indeed have been the easiest way of ensuring all the value of the MX80 licences was retained. The renewal would have also needed to include licensing for the two switches and at least two APs, plus any Systems Manager agents still needed (basically anything you still wanted to carry on working, after the renewal).

GreenMan · ‎Nov 16 2020

As the co-termination date is based upon the sum total of devices within the Organization, the extra value input by adding the new MX84 licences will be shared across all devices in the Dashboard. Unfortunately, it is not possible for Support to convert MX80 licences to MX84 ones, as @AnythingHosted suggested. Remaining license value, for devices being upgraded, can usually be taken into account in the commercial arrangements for purchasing the new hw and license, but that is usually done, in advance, via the Meraki account team.

About GreenMan

GreenMan

Community Record

Badges