Meraki

cmr · ‎Jun 2 2020

@akrammeraki how long did you wait? The reboot isn't instant and sometimes doesn't even show on the timeline. If you have someone local, or have a continuous ping to it from the LAN, then you should see it go off and back on.

cmr · ‎Jun 1 2020

I don't personally believe that cloud cameras are the way forward for this sort of scenario, they are mainly aimed at sites with a handful of cameras where normal NVR based solutions wouldn't be cost effective. We have sites with hundreds of cameras and as you have seen, the upload bandwidth would be prohibitive at ~250Mb/s for the quality settings we use. The storage does cost money as nothing is for free, we have ~1PB of storage for our surveillance systems and that is quite a big investment.

cmr · ‎May 29 2020

We use PSK with WPA2, I don't think the Mac based access control has encryption at all for association so MAC addresses can be sniffed and copied, so isn't suitable. We keep them on a separate VLAN and then out to the acquirer. They are Ingenico devices and this works well. Make sure you have the latest devices as the previous gen couldn't roam due to a firmware bug.

cmr · ‎May 28 2020

The failed state means that it cannot reach the primary monitored IP (8.8.8.8 in your case). If you add another monitoring IP that you can reach over that link and make that primary it will show as active.

cmr · ‎May 28 2020

@NolanHerring I think for me, on the WiFi5 chipset, there is a bit of both. The BSOD is clearly a driver issue but I'm pretty certain some of the performance is an AP firmware issue, as on 27.1 I even see radio dissociation messages during the timeouts on the AP and that doesn't happen at all with 26.8... 🤔

cmr · ‎May 27 2020

FYI the new package takes the 8260 to 20.70.17.1, so it does update, it looks from the .inf that the AX200 will be upgraded to 21.90.3.2 The fix list is below and whilst not directly mentioning Meraki, it does list some performance and disconnect issues with other vendor's APs. Also I thought my laptop was overheating as I have a few BSODs and, oh look, looks like Intel was the culprit! Key Issues Fixed and Changes: Package Version 21.90.3 When system connected to Wi-Fi 6 networks, Wi-Fi 6 enabled cellphones fail to connect to Mobile hotspot at 5 GHz. A disconnection might happen under specific scenarios, when connected to specific access points Apple* Airport or Asus* AX. Intel® Wireless-AC 9560 connection p to NETGEAR* Access Point Nighthawk RAX80 After resuming from Sleep mode on systems with Modern Standby, the Wi-Fi network scan list is empty. When streaming online videos, audio gets interrupted. Windows* Stop Errors (BSOD) caused by the Intel Wireless Driver. When hibernate or Shutdown followed by resume performed and Airplane mode is enabled, Bluetooth does not turn on upon exit Airplane mode. Reduced Wi-Fi throughput on specific channel. Intel® PROSet/Wireless Software 21.90.3 has been updated to include functional and security updates. Users should update to the latest version.

cmr · ‎May 27 2020

@NolanHerringit only appears to happen on the laptop, the driver version is 20.70.16.4 which was the latest for the 8260 until this week (the newer package didn't contain a newer driver) but I see 21.90.3 is now available at: https://downloadcenter.intel.com/download/29536/Intel-PROSet-Wireless-Software-and-Drivers-for-IT-Admins?product=86068 so I am going to see if that makes a difference.

cmr · ‎May 26 2020

The laptop is an XPS13 with Intel WiFi5 8260 chipset, had it four years and never seen this!

cmr · ‎May 26 2020

See below for results on 27.1: Reply from 192.168.1.254: bytes=32 time=197ms TTL=64 Reply from 192.168.1.254: bytes=32 time=314ms TTL=64 Reply from 192.168.1.254: bytes=32 time=517ms TTL=64 Reply from 192.168.1.254: bytes=32 time=21ms TTL=64 Reply from 192.168.1.254: bytes=32 time=957ms TTL=64 Reply from 192.168.1.254: bytes=32 time=7ms TTL=64 Reply from 192.168.1.254: bytes=32 time=453ms TTL=64 Request timed out. Reply from 192.168.1.254: bytes=32 time=188ms TTL=64 Reply from 192.168.1.254: bytes=32 time=809ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1320ms TTL=64 Request timed out. Reply from 192.168.1.254: bytes=32 time=156ms TTL=64 Reply from 192.168.1.254: bytes=32 time=53ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1198ms TTL=64 Reply from 192.168.1.254: bytes=32 time=399ms TTL=64 Reply from 192.168.1.254: bytes=32 time=827ms TTL=64 Reply from 192.168.1.254: bytes=32 time=23ms TTL=64 Reply from 192.168.1.254: bytes=32 time=450ms TTL=64 Request timed out. Reply from 192.168.1.254: bytes=32 time=51ms TTL=64 Request timed out. Reply from 192.168.1.254: bytes=32 time=87ms TTL=64 Reply from 192.168.1.254: bytes=32 time=92ms TTL=64 Reply from 192.168.1.254: bytes=32 time=402ms TTL=64 And then 26.8 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=3ms TTL=64 Reply from 192.168.1.254: bytes=32 time=6ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=3ms TTL=64 Reply from 192.168.1.254: bytes=32 time=3ms TTL=64 Reply from 192.168.1.254: bytes=32 time=62ms TTL=64 Reply from 192.168.1.254: bytes=32 time=74ms TTL=64 Reply from 192.168.1.254: bytes=32 time=3ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=8ms TTL=64 Reply from 192.168.1.254: bytes=32 time=5ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=3ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Reply from 192.168.1.254: bytes=32 time=5ms TTL=64 Reply from 192.168.1.254: bytes=32 time=4ms TTL=64 Is anyone else seeing this? Android/iOS devices seem okay

cmr · ‎May 24 2020

Indeed it was somewhat confusing me, though I think you mean Greenwich Mean Time 😉

cmr · ‎May 24 2020

Indeed, I didn't even think that the 24hr clock could be what @Shadius was referring to when he said military time. I love the differences within a (mostly) shared language!

cmr · ‎May 23 2020

On our dashboard it displays Month, Day, 24h time which as far as I am aware is standard US 24h format. Are you looking for Day, Month, 24h, i.e. a full non-US format?

cmr · ‎May 21 2020

You would connect it to the MX64 and then the clients would also be managed by the MX. You will need a power supply or PoE injector for the MR33

cmr · ‎May 17 2020

At the moment you have created two separate networks: one that is formed by the fios router where all clients get an IP address from the fios router. They can talk to each other and access the internet through the fios router. The MR33 itself is on this network. a second network for the MR33 clients where all wireless clients of the MR33 get an IP address from the MR33. They can only pass through it to talk to the fios router, its clients (if that setting is enabled) and the internet. They cannot talk to each other. They all appear to the fios router as being on the single IP address that the MR33's LAN port is using. If you change the SSID to bridge mode then all clients will behave as though they are directly connected to the fios router. They will all get their IP address from the DHCP server on it, be able to talk to each other (whether wirelessly connected to the MR33, or connected to the fios router directly) and be able to access the internet. The network subnet that did exist on the MR33, when the SSID was in NAT mode will disappear. You could enable the wireless on the fios router and if you set the SSIDs to be the same, clients would then be able to roam from the MR33 to the fios and back. This is only needed if the MR33 doesnt give you enough coverage and you would need to tell the MR33 that the fios wasn't a rogue AP. Only use this option if you need the extra coverage and the MR33 and fios are far enough apart, otherwise it will cause more harm than good!

cmr · ‎May 16 2020

You need to use bridge mode for the printer to see the PC. Use Meraki DHCP is for public WiFi in small spaces

cmr · ‎May 15 2020

No worries, glad it was a simple fix 😎

cmr · ‎May 15 2020

It could be routing or firewalling. For routing can you try a trace route to a remote site and the same from a site to a client VPN address. For firewalling remember the site to site VPN uses a different set of rules to normal firewalling so make sure you are checking the correct list.

cmr · ‎May 14 2020

If you want to manage a user's internet access using existing non Meraki APs you need an MX. Current MXs are 64,67,68,84,100,250 and 450 in order of power from least to greatest.

cmr · ‎May 14 2020

The MR33 cannot manage the other APs, it talks to the Meraki cloud for management. I'd just plug it into the Cisco switch.

cmr · ‎May 13 2020

Be careful as if you leave it in the inventory but not in a network, it can be claimed by someone else. Best option if you don't like the option of waiting for a week is to create a spare network to park unused Meraki hardware in, access points or other.

cmr · ‎May 8 2020

For the IP at the remote site you have IP on WAN and gateway is interface on L3 switch at main site

cmr · ‎May 8 2020

As long as the remote site is set to tunnel all traffic back to the main one and once it gets there it can get to the internet you will be fine. The main site has the mx in concentrator mode and you put a layer3 switch in between the WAN connection and it. The layer3 switch also routes to your corporate internet and it all works fine. So remote site: LAN->MX->WAN Main site: WAN->L3switch->MX | V Internet firewall Sorry for text pictures, hope it makes sense!

cmr · ‎May 8 2020

So the feature designed to assist roaming breaks it! 🤦‍♂️

cmr · ‎May 7 2020

I'd be surprised if the logs go back that far on the dashboard, on ours we only get 3 months, that's why you would normally have a SIEM solution for this kind of forensic check.

cmr · ‎May 7 2020

I'm guessing the MX64, MX84 and MX100 might be about to be replaced then...?

About cmr

cmr

Community Record

Badges