About GreenMan

GreenMan

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

GreenMan

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

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

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

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

GreenMan

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

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

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

GreenMan

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

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

You will need minimum R26 for v3 output

GreenMan

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

Is there something Meraki-related about this enquiry?

GreenMan

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

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

@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

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

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

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

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

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

From what you have described, while they may have asked for more information on how this looks in any other Organizations you may yourself have access to, I'm pretty certain Meraki Support will not be leaving it entirely to you to take this further or find other affected Organizations. While they may not be able to diagnose the issue directly themselves, I'm sure they will be seeking further assistance to troubleshoot your problem, elsewhere within Meraki. Could I suggest that, if this is urgent, you telephone Meraki Support for a further update - contact details are under Help > Get help > Still need help? > Call the Meraki Support team

GreenMan

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

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

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

GreenMan

Community Record

Badges