Quick answer, the existing MSP needs to work with the new MSP for this handover.    In a best case scenario, the existing MSP can do an org split and simply cut your side of network/licenses into a new independent org - which can then be managed by you and your new MSP. (assuming your individual networks are currently integrated into the MSP's org)   If your organization is handled by the existing MSP (as a separate entity), then simply changing the dashboard admins would be do the trick 🙂  ... View more

@Chapelhill_IT although it is already mentioned in the article @RWelch has shared above, the overall idea is as follows: - Carefully move all the vlans and their gateway IPs (except the MS management one) to the MS425  - As you are moving these VLANs - ensure correct static route on the MX as well pointing towards the MS425 for the correct subnets. - Once you MS switch is capable of handling most of the VLANs - only have one transit VLAN between the MX and the MS425. You can either do this via access port or trunk port with pruned VLANs. Also, ensure a static default route on the L3 MS towards the MX.  - Ensure that the management interface and transit VLAN SVI of the MS425 are two different IPs and management interface points to MX as its gateway.     Although, I have seen some scenarios where the customers are using more than just 1 transit VLAN between MX and Layer 3 MS - and it does work but not considered as best practice.  If you get into any complications when performing this task, just reach out to Meraki support via https://meraki.cisco.com/support/  ... View more

While I can’t share internal backend details around the bug, I can tell you that the issue relates to how the dashboard server communicates with the local device. During this interaction, the password delivered to the Meraki device by the dashboard appears to become 'corrupted', which leads to the problem you're seeing. As you already know, a workaround is available, and I can assure you that our team is actively prioritising a permanent fix. ... View more

Port level hardware issues are at Layer 1 of OSI layer, and generally speaking, there is a requirement of some sort of flow (either electrical signals for RJ45, or optical signals for fibre cables) to identify such issues.  The only exception I can think of (based on the cases I have worked on) - is where the ports are lit up on the switch even without anything connected to it. This is usually a backend wiring issue that qualifies the switch for RMA. So if you see anything suspicious going on with the switch, kindly raise a support ticket via https://meraki.cisco.com/support/  and we can assist you accordingly  ... View more

It is generally not a problem for two MX devices - set up for different organizations - to check in to the VPN registry from the same public IP address. Since the MX uses NAT, it will automatically assign different source ports, so there’s no conflict even though the public IP is the same. I’ve actually tested this myself by running multiple MXs behind my main device and it works just fine. The only thing to keep an eye on is the amount of traffic going through the main (top-tier) MX, just to make sure it can handle the load. Some customers connect their ISP device to a WAN switch, which then allows multiple MX devices to connect through that switch. This setup works especially well if the ISP provides IP addresses via DHCP, or if you have access to multiple public IPs. It’s a clean and efficient way to get multiple MXs online without much hassle. ... View more

A simple and quick hack here will be to connect the MX device exactly as it was earlier, and doing a factory reset on it to clean up any stuck processes/mis-configurations. Please make sure that if the MX was using a static WAN IP, you are adding it again after the reset. If the issue still persists after this step, then the problem might be somewhere else and you can raise a support ticket with Meraki to get it checked further.   Factory Reset   ... View more

There are many moving parts that can cause this issue, but the first thing to understand is that 'factory reset' will clear up any IP addressing that existed on the device. So if you were using a static IP on the switch, it will be gone after the factory reset. After that, the switch starts using its default IP settings as DHCP and sends requests with the source of quad-zero (0.0.0.0) till it gets a DHCP assigned IP (or till you re-add the static IP addressing again). Personally, I don't think IGMP will cause issues with dashboard communication. As @alemabrahao  mentioned and since there are so many unknowns, raise a support ticket while having someone on site for the reset. The best way forward here will be to take a packet capture on an upstream switch while the downstream one is going through a factory reset. This way, we can see the traffic coming from the switch post-reset and verify its behavior.  ... View more

@ConnorL  is perfectly on point here. You should be seeing reCaptcha widget when you are on this page. See my step-by-step screenshots below, for reference:   This is often due to browser issues, temporary network problems, or extensions interfering with the process. Try another browser (possibly incognito mode) - to verify if this behavior is across different browsers. If you see this across different browsers, try using another ISP connection (or phone hotspot) for comparison. ... View more

Greetings, When we connect the WAN cable of the MX to another device (ISP modem etc.) - by default it sends DHCP Discover messages to try to obtain an IP address. If the upstream device is running as a DHCP server, the MX gets an IP address (by completing DHCP DORA process) and then tries to go to Internet + Meraki dashboard via that gateway. However, there are many instances where the ISP modem might not be running as a DHCP server and requires the customers to manually configure a static IP address. So the first test is to understand, whether the upstream device is running as a DHCP server or not. As a quick test, instead of using MX105 WAN interface, you can connect that upstream device to your laptop to check if the laptop gets an IP address or not.  For the MX part, the local status page will give you the best information here. In the "Ethernet" section - you will see one of two scenarios: - "This security appliance is connected to a local network" - this means your MX has an IP and gateway is working fine  - "The security appliance is trying to join a network or find a working ethernet connection" - this means your MX does not have a working IP or the gateway IP is not responding to our ARP requests    As per your second comment, if you are trying to connect this MX105 as a LAN client on another MX device, please make sure that the port you are connecting to is using correct native VLANs and not dropping untagged messages (as DHCP messages from MX105 WAN will be untagged). To drill down even further, you can also run pcap on MX LAN interface to check the DHCP exchange between the existing MX and MX105 WAN. This way you can see exactly on which step the DHCP is failing.  If the issue still persists, please reach out to Cisco Meraki support via https://meraki.cisco.com/support/ and one of our engineers can check this for you. ... View more

The answer to your question is very subjective and highly dependent on the logical flow of traffic in the network.  If you create 7 new VLANs (1 VLAN per floor), surely the size of each broadcast domain gets smaller. But if there is a lot of traffic flowing between these 7 VLANs, you are putting more load on the L3 gateway device (CPU specifically) as it has to now deal with extra inter-vlan traffic  - something that would not be required if all 700 users were in same broadcast domain (since in L2 communication, nodes can directly talk to each other via source/destination MAC without requiring any L3 involvement). I personally have worked on some cases where the CPU of the gateway device has spiked from 40% to 80% because of this. If the majority of this wireless traffic is northbound (going out towards gateway/Internet) - then surely segmenting it on a per-floor basis would be a smart move. You can find more information on high-density deployments in this KB: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MR_Wireless/High_Density_Wi-Fi_Deployments ... View more

Hi Shubh, This is a known issue that our DEV ENG team is currently investigating, please bear with us at the moment while we get this fixed for you.    I can see you have already raised a support ticket with us. We will update you via the same thread. ... View more

As @BlakeRichardson  said, I have seen similar situations where the device is not claimed in a network (but present in the organisation inventory).  In this situation, the MR44 is not a part of a network and , as a result, cannot download any specific configuration. Alternatively, there could be an issue with dashboard communication. Please raise a support ticket and we can investigate it further for you. KB for detailed reference: https://documentation.meraki.com/MR/MR_Installation_Guides/MR44_Installation_Guide  ... View more

Lets monitor this for a few days. If the switch behaves nice and normal throughout, we will know our issue is resolved 🙂  ... View more

If the switch is working fine in terms of traffic forwarding, it is possible that either it is not storing its own logs properly or (if the logs are stored correctly) they are not sent to the dashboard correctly. I would be very interested to see the behavior when we change the MASTER of a stack to a different stack member (something Meraki Support can check) or with a firmware change. But overall, I would raise a support ticket regarding this and call the support line via https://meraki.cisco.com/support/ to have an engineer check the internal configuration/logs of the device and verify this for you.   ... View more

While your reasons are genuine and the desired topology may work practically, it won't be officially supported on the Meraki end and if it comes down to troubleshooting it with a support personnel, they might ask you to revert back to ring topology. Again, as per my earlier answer, you will have to deploy it at your own risk 🙂   ... View more

I did some digging on this one. So Meraki uses a proprietary protocol using which different members of a stack communicate with each other. Going by the tradition and KB information, it is recommended to use a basic ring topology to connect the stack members. Although based on internal tests even non-ring topology (similar to one you shared in the picture) worked fine as a stack - however - this is not officially support by Meraki and should be used at your own risk. I hope this answers your question 🙂   ... View more

A single default gateway should work fine. Since you are doing routing on the MS225 stack, you will have to configure a static default route pointing towards a single IP address residing on the firewalls. Now if you are adding a redundant pair of firewalls, only one of them will be active/master at any given time which will be the owner of the IP that the switch stack is using as a gateway. There are some firewall vendors that use the (virtual IP/ virtual MAC) in their HA firewall setup (as @GreenMan  mentioned), in that case the gateway of the switches will point to the virtual IP that the HA firewall share.   As long as you have physical connectivity between the stack switches and both HA pair firewalls, STP will do it its magic and redundancy will take care of any failover scenarios.      ... View more