The typical powering options for a camera would be PoE (switch or injector) for sure ... View more

Technically yes it can work. But you'd need an adapter for the barrel connector side of the power supply. I've used this one as a way to connect this power supply to our low voltage power adapter then eth/PoE out to Cameras and APs.   Or I suppose one could just cut the end of the power supply and expose the wires and connect it into the block on the MV52. Obviously that's stepping further outside the box. ... View more

Looking at pcaps I see when it pings a RFC1918 IP the source is the highest VLAN IP with VPN enabled. When pinging a "public" IP the source is the WAN IP.  ... View more

Where are you pinging from? Looking at your config I see the 178.x.x.x advertised from two hubs. Choosing a random spoke site I see the MX has two VLANs, neither enabled for VPN. The static route down to your L3 switch has VPN enabled.    So, from L3 interfaces on the downstream switch I can ping 178.x.x.x IPs which makes sense. The MX however cannot ping 178.x.x.x as it's sourcing from its interfaces none of which are enabled for VPN. And Insight would be using a MX interface to source pings from.   You may also want to ask Support if the MX should be able to ping a public IP via AutoVPN or if it's not following the route table and instead seeing a public IP and just skipping to sending it out the WAN interface. ... View more

Yeah it would be using MQTT (AFAIK) because that's a streaming protocol. API isn't a stream and rather a push/pull type service.  ... View more

Topic is covered here https://documentation.meraki.com/MT/MT_General_Articles/MT_MQTT_Setup_Guide. The sensor gateway (Camera or Access Point) is the one using MQTT to communicate with the MQTT broker. ... View more

Were these devices part of a trial? ... View more

It appears your key only covers the switches, MX100, and 5 APs. So if you try to apply as a renewal it will remove the MX67 because that's not in the license key. Sounds like the license order wasn't correct. ... View more

I've had the same issue on & off and reported it to PM. My advice is open a ticket so more eyes can be placed on this.   I too am not using a MS390 and don't have adaptive policy enabled anywhere.  ... View more

We don't know what other routing is in play here. My point is regardless that ping test isn't valid.   There'd still be a 0.0.0.0 default route to the hub even though the VLAN isn't VPN enabled. And because the MX VLAN interface doesn't NAT it's hitting that hub default route. ... View more

If I'm understanding your scenario and test of pinging from a MX VLAN interface to the internet that's not supported as the traffic is not natted as noted here.   https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Ping_Live_Tool#Behavior_-_Firmware_MX_15.12_or_Higher   For example this is from my MX   ... View more

MX doesn't support LACP. So, if you have LACP (port aggregation groups) configured on the switches delete those. ... View more

I'd recommend you have a design session with your Meraki SE on this one.   But yes, you could take an approach of regional hubs. Full mesh tunnel count can get high real quick especially if you have dual WAN links on the MXs. 150 sites of full mesh with single WAN links would be 149 tunnels per MX. So per the MX Sizing Guide you'd want to have MX95's minimum.   If this is an international deployment perhaps designate one hub (or HA pair) per region and then have local spokes use that as primary and maybe use another regions hub as the secondary.  ... View more

Please open a Support case ... View more

I see a fair amount of Ethernet port carrier change events in the log. Are those all due to testing (disconnecting/connecting the servers, power cycling the servers, etc)? Only 2 events today, but ~30 events on 6/19 and quite a few on 6/14, 6/17, 6/18. ... View more

Ok, so the 3 servers are currently connected directly to the MX.    Can this be replicated basically anytime you run a constant ping? Or, does it follow any sort of pattern, time of day, etc?   Throughput on the MX looks good. I don't see any real periods of high CPU or high flow counts. From my vantage point it all looks like it should be a healthy network.   I do see a fair amount of DHCP no offer and Source IP and/or VLAN mismatch events in the log. But those typically wouldn't explain the behavior you're seeing. Although when I see lots of events like that it always makes me dig deeper into the entire topology to look for a switch or other device causing general network weirdness. ... View more

You already RMA'd the MX75 and tried a MX67 and the problem persists. I can't imagine trying yet another MX67 is going to change the results.   I also see Support changed the MTU and MSS clamping for you. Any difference with those tweaks in place?   I took a look at your MX and other than small blips on the loss chart for the WAN link over time I don't see anything that catches my eye in your config.   You mentioned running ping tests on a server. What was the destination? The MX LAN IP, another LAN IP, internet IP? Also, do you see the same loss when pinging from non server clients or the switch (if it's a managed switch that allows for it)?   Also, what is the complete topology of the site? I see LAN ports 4, 7, 8, 9 are active. What do they connect to? ... View more

Yes, the MS425 supports 1Gbps transceiver in the SFP+ ports.   https://documentation.meraki.com/MS/MS_Overview_and_Specifications/MS425_Overview_and_Specifications?file   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/SFP_and_Stacking_Accessories  ... View more

You should contact Meraki Support ... View more

The topic is covered here    https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/SP-Initiated_SAML_SSO_Configuration_Guide#Defining_a_unique_subdomain_for_your_organization ... View more

If I'm following your description of the topology the MX is the edge FW for this remote site. Outbound traffic will be natted to the WAN int IP. It sounds more like you want a traditional router function here vs. what the MX is going to do which is NAT on the outbound.   I'd say either run DHCP on the MX or use AutoVPN to a headend MX so there's a routed VPN path and NAT doesn't come into play. ... View more