Meraki

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.

GreenMan · ‎Nov 16 2020

There's no simple answer to this; consider that, if you enable BGP on a Hub MX, to advertise your branch subnets into the Data Centre, you will also be learning routes from the eBGP peer in the DC, which will then be advertised to all the Spoke MXs of that Hub. As the Spoke MXs tend to be 'smaller' units than Hub MXs (e.g. MX67, compared to MX250) - and because DCs often learn lots of routes, it is generally easier to overload the Spokes than the Hubs. Look to limit the routes advertised from the upstream eBGP peer and summarise where possible. Look for <150 routes learned via eBGP, to protect the spokes Unless you have an unusually large number of subnets, per branch, if you follow the scaling guidelines in the MX Sizing Guide - particularly for tunnels & VPN throughput in particular - I think you're unlikely to hit a scaling limitation on the Meraki Hub end. Also look into the impact of the routes advertised to the upstream eBGP peer in the DC.

GreenMan · ‎Nov 16 2020

Actually, I learned something new myself, here; you can clone using the API. It's covered within the main API documentation, under Create Organization Network https://developer.cisco.com/meraki/api-v1/#!create-organization-network and use the copyFromNetworkId parameter Note that I'm pretty sure you will want to configure your Azure vMX as a Hub, with all of your branches configured as Spokes, tunnelled to that Hub. In that setup, you would have no tunnels to either your DC or your Head Office. You don't need to use OSPF at the Hub vMX. I'm pretty sure you will also want your branches (Spokes) in Routed mode, with VLANs and your Azure vMX Hub in VPN Concentrator mode.

GreenMan · ‎Nov 16 2020

All this is likely the case because Network Objects is in Beta. As and when that's no longer the case, the relevant documentation and tools get promptly updated, in my experience. @Kiran_Oddiraju the documentation I linked in my initial reply makes it clear that both FQDN and Wildcard FQDN are supported. For use within the API substitute "type":"fqdn" within the cURL example provided

GreenMan · ‎Nov 13 2020

It seems to me that the key thing here is to unclaim the license you claimed as a renewal, as per the instructions in the document you referenced. When you claim a renewal in a co-term Organization, you must include a license for every device that you want to carry on working afterwards (i.e., including your MX67's) Ajit is right that you must have the same license level for all MXs in an Organization. If you want Advanced Security, then once you have unclaimed the renewal you should ask Support to convert the Organization to Advanced Security (you will see the license time, til renewal shortens - as Adv Sec uses MX license time at twice the rate of Enterprise) You will then be able to claim the license with the MX250 Adv Sec into your Adv Sec Organization. With all your MXs in the same Organization, setting up (Auto)VPN between them will be so much easier and more powerful than setting up non-Meraki VPNs between the MXs in different Organizations.

GreenMan · ‎Nov 13 2020

It sounds like the DHCP scope configured within the MX, for the VLAN in question, hasn't been configured to serve clients with the right (internal) DNS server address(es). have a look in here, for the VLAN in question: Security appliance > Configure > DHCP Refer to this documentation: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Configuring_DHCP_Services_on_the_MX_and_MS I think this is the most relevant line: Specify nameservers... - Clients will be given a list of DNS servers configured by the administrator. These servers are listed in the Custom nameservers box that will appear, with a single address per line.

GreenMan · ‎Nov 13 2020

Yes, this is possible in the way you describe. Please consult this KB article: https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Moving_Devices_Between_Organizations#:~:text=Once%20devices%20have%20been%20moved,remaining%20value%20can%20be%20moved. Bear in mind that, if you do nothing else, unless there is at least one spare AP licence in the Org to which you move the AP, you will - when you place the AP in a Network - make the Org out of license compliance and it will go into a 30 day grace period (this assumes the Org is running co-termination licensing) Org admins will see the red 'License problem' banner in Dashboard and various related warning emails etc. This can cause alarm, of course... More importantly, if you don't remove the AP again, within the grace period, to return it to compliance, the Organization will be shut down (see doc below) https://documentation.meraki.com/General_Administration/Licensing/License_Problem_-_Out_of_Compliance To avoid this, you can call Support and ask them to 'move' a license too.

GreenMan · ‎Nov 13 2020

It woulr probably be best for you to log a Support case with Meraki for this, if I'm honest...

GreenMan · ‎Nov 13 2020

OK - as I mentioned, I'm afraid there's little chance of there being any further development into info via SNMP. Are you using the SNMP option which polls the Meraki Dashboard as a single entity, for all Meraki devices in an Organization - of have you tried polling devices directly? (which is also supported) API is the way of the future and not just for Cisco Meraki, I would say. Note that the calls which @Phil shouted up are both Org-wide: you get all the info pertaining, with a single call, covering all devices in an Organization - rather than needing to collect a list of all devices with an initial call, then iterating through that with a separate call, for each one. Meraki have been looking to increase the number and variety of similar calls, where possible, as one way of reducing the number of calls required to gather useful info.

GreenMan · ‎Nov 13 2020

By Microsoft cloud I assume you mean Azure - in which case, have you considered deploying Virtual MX (vMX) as part of your AutoVPN? This could work well with the kind of multi-hub setup I described earlier, with branches (Spokes) having tunnels to both HO (for current setup) and Azure (future setup) and allowing a gradual move of applications between the two.

GreenMan · ‎Nov 13 2020

It sounds like your services may actually be hosted in the DC, rather than the Head Office? If that's the case, why not put the Hub in the DC and build the tunnels from all your sites to the DC Hub - including from the HO? That way, you don't hairpin traffic in and out of HO and you may not need to pay for the dedicated link. If you host services in Head Office and the DC, maybe put a Hub in both and build a tunnel from each Spoke to both Hubs - traffic will then take the most direct route - and the HO <-> DC link (if you still want it) will be less congested?

GreenMan · ‎Nov 12 2020

Unfortunately, that's not where the Access Point is looking for it - hence the failure, I'm pretty sure. I'm afraid I've not got any experience with PacketFence - and some basic Googling didn't really come up with anything either...

GreenMan · ‎Nov 12 2020

Sí, si tiene un ANT-25, conecte ambas colas a la misma radio. Debido a que es de doble banda, puede usarlo en la radio de 2.4 o 5 GHz, pero no divida los cables entre las dos radios. Si usa ANT-20, asegúrese de que ambos postes de antena de la radio tengan un ANT-20 conectado. También es de doble banda, por lo que puede usarlo en 2.4, 5 o ambos (4 antenas). No deje ningún poste de antena desconectado; es malo para su rendimiento inalámbrico y malo para la radio. Debe configurar el AP para las antenas que ha conectado. En Inalámbrico> Configurar> Configuración de radio, seleccione el AP y elija la antena adjunta para cada radio en los menús desplegables. He utilizado el traductor de Google del inglés, así que espero que todavía puedas entenderlo. Me temo que no hablo español.

GreenMan · ‎Nov 12 2020

From my experience, different levels of Layer-3 support is common across many manufacturers, for their more price-sensitive product lines (there's a reason why they cost less). That tends to fall in much the same way; starts with routing between directly connected VLANs + static routes, probably with a limited number of routes - then adds features & capacity (and usually complexity!) as the cost of the models goes up. I think attention to detail, in reviewing available documentation, in advance of purchase, is definitely recommended, regardless of manufacturer. Layer-3 is just one of those blanket terms that covers a variety of actual technologies. if you specifically want any of those technologies, best to check they're supported, up-front.

About GreenMan

GreenMan

Community Record

Badges