Make sure ALL your AP's have been added as Radius clients on your radius server and that their pre shared key is correct. Then you should be looking at your radius logs to see what is going on. You can also capture traffic leaving the AP on the wired port and filter on port 1812 to see the conversation between the AP and the radius server.  You get at treasure trove of information like the AV pairs exchanged.   Also you may be not matching the incoming session in your policy list.  Wireless has a different NAS-port type than a switch. ... View more

Bad roams or suboptimal roams usually has to do with the client choosing the wrong AP to roam to. In the roaming analytics you should see the RSSI of the previous AP and the next AP.  If the next AP has the same or lower RSSI than the old one the roam is suboptimal or bad.  If that is the case your issue is wireless design, not wired network.  The roaming analytics feature is quite new so you may not have had these messages before. ... View more

You are talking about auto VPN between an MX and a vMX.  That means you can just choose 1 WAN or concurrently both WAN's.  You don't need to do anything.  That means you don't need an IPsec VPN as backup since the autoVPN is already redundant via your both WAN's. ... View more

Your AP's are storing all the PSK's and doing the brute force on each key to be able to come to the correct one to continue the 4 way handshake.  If you are getting issues with certain clients using key 1 and other clients using the same key don't have the issue you could be running into a bug on the AP and maybe you should retry after rebooting the AP.  Maybe check if you have a recent update. ... View more

If you are doing routed subnets on your MS switch then the first interface needs to be your upstream interface you use for routing to the internet.  That's why the GUI is built this way.  They make you do your upstream VLAN first that contains the 0.0.0.0/0 route.   Only after you have done that you can create the other interfaces for local routing. ... View more

Also when you try to add firewall rules to the Meraki firewall that do not contain any local subnets you may get an error at saving.  There is a sanity check which can get in the way especially in cloning network that wants to force only rules that would have any chance in matching source IP addresses. ... View more

It isn't best practice but it would work for SD-WAN traffic and outbound traffic. Port forwarding is problematic since you have a completely different IP subnet on your secondary so in a device failure scenario those won't work. It would be better if you could stretch both ISP's to both datarooms and having a /29 subnet or a private NAT'ed subnet. ... View more

The sonicwall has a quite complex NAT and policy ruleset.  You really need someone that can interpret the Sonicwall correctly to understand and implement the ruleset on your Meraki device. ... View more

It will work as it is now but it is in fact a failure scenario.  You should invest that little 100-ish$ for the second cable and just connect the full ring. ... View more

The only test you can use is the dashboard throughput test but this is still not 100% accurate since the dashboard itself is not a tool for speedtesting. Since your throughput is limited by the wireless aspect anyway it could be a good idea to have the highest speed wireless client close to the AP in ideal circumstances and a wide channel so you have the highest PHY possible and make sure that client is the only one connected at that time to test and use iPerf between that wireless client towards a wired client on the same switch where the AP is wired to so you have the best possible scenario.  Do mind that even if you use a 4x4 AP your client will be 2x2 at most. A good reference is to acount for about 5/6th's of your PHY speed as throughput to what you should be getting at between your clients. If the result is way lower than you expect then you still have to determine is the issue is on the wireless side or the wired side by checking out the airtime and do an OTA to double check if the AP is doing nice aggregated data packets. ... View more

If the DNA version of the Access Point can be deployed in Sri Lanka (CW9166I-ROW) then the Meraki version can be used too. So if you want a 100% guarantee the AP models can be sold then you should contact the local Cisco distributor directly. The difference is as I said before that the Cisco DNA versions have to be bought with the regulatory area in the partnumber whilst the -MR version just enforces it through software. ... View more

If you connect to the back with an ethernet cable you will automatically get an IP address and a browser popup will take you to the local page. If you're connected on a regular port on the switch you can reach it if your are in the 1.1.1.0/24 network and you try to reach 1.1.1.100. ... View more

If you buy a Meraki AP the country code is not baked into the AP.  It will grab the country code from your network and surrounding Wi-Fi devices and then set the country code accordingly.  Alternatively you can also enable manual setting of the country code of a wireless Meraki network but you will have to click some disclaimers since you take the responsability for the correctness. ... View more

Then there is a possibility the problem lies with that specific Apple TV unit. If possible try with another unit that works with the other cameras and compare the hardware versions and the firmware versions on the AppleTV units if the result is different. ... View more

So you are saying the apple TV that is on the same layer 2 segment as the cameras at that site is having the streaming issue? Do you have the posibility to mirror traffic on the switches?  You could verify if the network is delivering the traffic to the endpoint (apple TV) by doing a capture in a site that is working and using the wireshark IO graph to check packets per second and bits per second and comparing that to a capture on the problematic site. ... View more

Unless you have spanning tree blocked links you should be 100% sure where your traffic should go.  If you want to check for sure you could log in to both of your Netgear switches and locate the MAC addresses of both endpoints so you verify on the left switch where the MAC address of the endpoints on the right switch are coming in from and vice versa.  If you break the links between the Meraki switch and the Netgear switch and your mac addresses were on the switchlinks between both Netgears instead you will not have any interruption of your iSCSI traffic. So while you can reason it by using networking logic you should definitely doublecheck using the mac address tables on both switches to be 1000% sure before unplugging anything 😉 ... View more

Can you move the management for those Netgear switches off to another VLAN not used by the iSCSI traffic?  Then you could just prune the VLAN off the trunk between your Meraki and Netgear switches.  This is the only solution that is watertight. If you can't do that and the management traffic of the netgears are on the same VLAN as the iSCSI hosts then you should create an ACL where you first allow the traffic on that VLAN from the two netgear IP's and then deny all incoming traffic from the rest of that specific VLAN and subnet.  There is an allow any at the end of the switch ACL that will of course allow all your other network traffic. ... View more

Talk about timetravelling 😉 So the while the management of the core switches itself is separate from the routing that it provides for downstream devices the limitation is that you cannot use the routing of the core switch to route it's own management traffic.  So in case you want to use the same subnet for management of the core as it's own uplink you need to have that subnet large enough so it fits both upstream ISP router IP(s) the core stack SVI AND the management IP's of both stackmembers.  And yes the router of the ISP is then the default gateway for the management of the core switch.   About the switch settings page.  You are welcome to enter a VLAN ID there which will become the default for all the MS switches in the same network that DO NOT have a VLAN ID configured on their own management settings.  So you could enter for example VLAN 100 as management that has an SVI on the core switch to route the downstream switch mgmt while having a different VLAN ID on the core switches themselves by entering the VLAN ID individually on both core switch mgmt IP. ... View more

The only thing you need to be aware of is that you will have to remove the uplink of that switch before adding the stack links or you could have a spanning-tree issue because stack ports keep forwarding.  You will also have a warning on the switch for a couple of hours after linking it.  Even when you configure it as part of the stack it will take a little while before the warning goes away and the switch will  have a green status in dashboard. ... View more

I have also noticed this behavior this week. ... View more

@AmyReyesI haven't received it yet.  If you could give an indication when it will be arriving then we know if someone needs to be home.  Thanks! ... View more

Not everything can be WiFi 6E.  So until WiFi 7 comes out I don't see it going EOL that fast. Secondly we have the MR46E which is the only WiFi 6 indoor model with external antennas.  WiFi 6E does not allow for external antennas at least in ETSI regulatory area so I do see a big use case for regular Wi-Fi 6 for the time being. I do think the MR46E will remain longer thane MR44. ... View more

I'm also gonna post the same answer as some of my colleagues did. The reason why you are getting response not found in captures is probably because some of the ICMP echo's are reaching the MX which shouldn't normally since intra-VLAN traffic does not pass the firewall since hosts will directly communicate to each other based on their source and destination MAC addresses.   The only few reasons I can think is that the client is perhaps using the MAC address of the MX as destination erroneously instead of the endpoint.  Or that the switch is flooding the frame to the MX also while the response is not being flooded.  Or that your endpoints are both directly on the LAN ports of the MX.   You would need to check the capture itself and really look at the source and destination mac addresses being used while having the endpoints mac addresses to check.   It is also important to know that switched traffic on an MX will not be treated as "forwarding" traffic and will not be subject to the L3/4 rules.  Only an MX in passthrough mode could have this but then you are using the WAN1 port and that traffic will be subject to the rules. ... View more

Oh? I haven't received anything yet. We can however only judge if you look good in it if you post a picture of you actually wearing it 😉 ... View more