Unfortunately the KB is unlikely to be updated. I personally have gone in and done the calculation several times manually to update the kb. The problem is that when we come out with a new range of OUI the calculation changes. As the number of AP that we sell as well as new models increases, we can’t keep up with a definitive list. I would like to think that my nagging about the BSSID calculation always changing is why we came out with the API for it (but probably not).  This is in beta and the behavior WILL change and it might not even work for your particular use case. But, you might want to check out the new MR28 beta. Still probably a way out for being the stable. But the cool thing is that you can now customize the called-station-ID and NAS-ID for 802.1X connections. Now instead of using the BSSID you can specify the MAC address of the AP. (In a case of this being beta BSSID can’t be configured for the time being).    Again it’s still in beta so I would report any bugs to support but it could take a while to resolve (but better to test now than to wait for stable).    ... View more

From what Engineering has told Support this is "expected behavior." I don't have a better answer than that. They do look at wishes so I would wish for it. Unfortunately, Support won't be able to do anything about it.  ... View more

Not quite sure if I'm misunderstanding what you're trying to determine.   Do both of the DNS CNAMEs point to the same MX? I would think that you would be pointing to a different MX depending on which VPN hostname they connected to. In which case the clients would be listed in two separate networks. vpn1 will be for MX1 in network 1. vpn2 will be for MX2 in network 2. Each site will have its own client VPN subnet that is being used to hand out IP addresses. You could deduce which VPN they are connected to by looking at the IP address that the client received from the MX.    Even if you're using a DNS load balancer to spread out the clients, you would only see the client connecting on the network that they ultimately get routed to. However, in this case, you wouldn't really be able to rely on any of the historical numbers as users could easily be hopping from one to another.    https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Load_Sharing ... View more

An observation The printer is likely showing offline in dashboard because it isn't passing any traffic. Once it starts passing traffic it will show up as an active client. Once it stops it will likely go "offline" in dashboard. Totally expected behavior as we use traffic as a way to determine if it's online.   Some suggested avenues of troubleshooting. I apologize if this is above your comfort level, this is a public forum so I'm trying to include as much information as possible in case others might benefit. If that's the case you might go ahead and speak with Meraki Support.    Checking settings Does the printer have an IP address? Is it set to use DHCP? You mentioned you're not seeing a lease in dashboard, what about from the printer help page? Can the printer IP be set manually? Is it the correct IP address according to the vlan that you have it in? Is your MX port configured correctly? Probably easiest setting it up as an access port with the same vlan as all your other clients.  If you're still in port 2, make sure that it's not configured as an internet uplink.    Verify connectivity Are you able to ping the printer? Are you able to access the printer's web interface? (assuming it has one)   Troubleshoot the printing problem If you're familiar with Wireshark I would suggest you take a packet capture on the LAN interface of the MX with a filter expression of "host IPofPrinter" (it might just be easier to start by taking a packet capture on the wired computer). See how it's communicating, and the type of traffic that it's sending. If you're not familiar with Wireshark, now might be a great opportunity to take a peek at what's going on. If you check out my Wireshark community post, I have some information about getting started. Based on the age that you mentioned, the thing that I would be interested in most is seeing if the computer and printer can form a TCP handshake: SYN, SYN-ACK, ACK. It could very well be some other method that you'd need to find from the manufacture.    To troubleshoot why it isn't getting an IP, we need to see all the communication on the LAN. So I'd recommend a filter expression of "not host MYcomputerIP.    Meraki Support can certainly take a look as well, to make sure everything is set up correctly. Probably best done by calling so we can troubleshoot this live. Based on that, they'd be able to give you some more specific next steps.    Footnote. The reason it might be easier to take a packet capture from the computer is that when you're doing a LAN capture (and aren't using a filter expression) on the same MX that your computer is connected to, is because otherwise, you start capturing that capture of your capture. It's recursion all the way down to a very large file and likely a failed download. So when you're on the LAN of the MX, it's always best to use a filter expression of the device you're troubleshooting or "not host MYcomputerIP".       ... View more

From what you've described, it sounds like the device is indeed checking in, albeit using DHCP. You should just be able to use the pencil icon next to WAN1 on the uplink tab.    There are multiple reasons that you could be getting that error, but the most common cause is that the static gateway that you have defined is NOT responding to ARPs. Since the default gateway isn't responding it's not able to use the address that you have defined and will fail back to DHCP. A packet capture on the internet interface will help determine whether or not that's the case. If it is then, you'd likely need to talk to the ISP as to why there is no response. If it is simply a misconfiguration you can simply change via the dashboard.   ... View more

I'm pretty sure this message was passed along to you already, but just to post for the benefit of the community.   The problem is in the authorizations section. It needs to be an array not just an object. Here's a screenshot of what it would look like in Postman.   ... View more

Right off the bat without knowing more, I'm going to take a stab in the dark. One common mistake is that the VLAN tag is being set. If the native vlan of the switch port is the same vlan that you're wanting the AP to be on, then there is no need to set the vlan in the static IP. If you have it, then remove the vlan tag. If the native vlan is different than the vlan you want the AP to be on, then you'll need the vlan tag.    If that doesn't fix, take a pcap of the wired interface of the AP. You should see it ARPing for the mac address of the default gateway that you have configured. If it's not getting a response, then it's going to use DHCP. It will continue ARPing to see if it becomes available. If it's getting a response from the gateway then it might be best to give Support a call to have them take a look.        ... View more

My apologies. That warning is about setting a public IP directly accessible to the internet on the VPN concentrator. I thought you were referring to setting manual NAT traversal. We were talking about two different things.    As for my recommendation on manual NAT traversal, I'm not sure how else to explain it. I still recommend setting manual NAT traversal. I understand you have 2 internet circuits. The manual NAT traversal locks the MX to a certain port then relies on the VPN registry to teach the second ISP public IP to the spokes. However, in your case, the Palo Alto might be stopping that traffic from getting out so it might not have worked anyway.    I do not recommend opening all the ports. If you leave the NAT traversal set to auto, I would recommend that you open only the port that is currently being used. You can find that one the VPN status page.  ... View more

I strongly agree with having an incoming rule to allow the UDP flow. (Not sure where we say that we don't recommend it, it's a practice that I'll commonly make.) You'll want to setup a manual NAT traversal with a specific port. You would probably want to have that port set up as a port forward on both uplinks. If the VPN concentrator able to communicate with the VPN registry on the failover, then the spokes might be able to create new sessions to the concentrator. I don't know if the traffic from the concentrator to the spoke would still get black-holed but it might be worth a try.    The reason you want the manual NAT traversal is it will prevent a new one from being picked at random. Otherwise every time the port changes on the MX then you'd have to change your inbound rules. In terms of security, it would be similar to having a webserver port forward. There's a resource that needs to be accessed but we rely on the webserver being up to date to prevent malicious use while still maintaining access to the resource. In this case the MX is the server being accessed and it has builtin security to only allow valid VPN connections. If you really want to lock it down then you could create allow lists with the public IP of all of the spokes. But that might be a bit onerous to upkeep.                ... View more

I went into more detail on the other thread but I think manual NAT traversal might be helpful even in this situation. Instead of clearing all of the sessions on the Palo Alto, you could manually change the NAT traversal information on the VPN concentrator to force all of the spokes to change the port and IP address to connect to. This is by no means a perfect solution as the same thing could potentially happen when the uplink is restored (I don't understand the intricacies that you're running into on the Palo Alto side). The key point of the change though is to change the port that is being used. All of the spokes would see that the port had changed and would need to re-establish the VPN. Since a new port is being used a new flow would be created on the Palo Alto. It's not a solution but another avenue that can be used while troubleshooting with Palo Alto.  ... View more

I named my access point, BSSID. Here you can see that I'm searching for 9a:18:98:fb:xx:yy, in the results I'm getting a result of the access point BSSID that includes the true mac address of the device 98:18:88:fb:xx:yy. If you have a large organization then this search might not work in order to optimize the page. Is that not working?      Not sure what you mean by BSSIDs appearing "on the wire". The BSSIDs shouldn't be appearing on the LAN side of the AP, but I could be misunderstanding you.  ... View more

It sounds like you're tagging the SSID to be the same VLAN (999) as the native vlan on the switch (also 999). Is that correct? If that's the case then you would want to have VLAN tagging disabled on the SSID. By having it on both will cause problems. You would only want to set a VLAN tag on the SSID if you are wanting the client to have a different VLAN than the native vlan.    If I've misunderstood then some other questions. Are other devices able to join the SSID? Do those devices get the correct IP address? Is it only the Tesla that has a problem with the SSID? Any problems reported in Wireless Health? ... View more

If you just want the AP name then you can search for it at the top of the page and it should give you the name of the AP there. Unfortunately, the BSSID isn't always predictable, and depending on the model of the AP the pattern will change. However, as a general rule, the 4th and 5th octet of the BSSID will match the 4th and 5th octet of the MR's base mac address.    The API would allow you to get your own list of BSSIDs that you could refer to.    If you would like a list of the BSSIDs displayed on the AP then you can open a case referring to this kb and say that you want to see the BSSIDs in the dashboard itself without needing to use the API.    Another option would be to have Support enable the AP to broadcast the name of the AP in the beacon. If you're on a mac then the tool WiFi Explorer would then be able to populate that. If you open a case referring to this kb, then Support would be able to enable it for you. The device name was removed from MR25.12 firmware "Removed device-name from CCX extensions as default but can be enabled." This has to be enabled on a network by network basis so might be best if you start with a small deployment. If you have hundreds of networks I would recommend calling and talking with Support about the most efficient way of making the change. (They might want to have you spread it over a couple of cases. I don't anticipate it causing major disruption but if you have a strict change window then I would recommend creating the case then calling Support during your change window.) It was removed for a reason, but I've been running it on all of my lab devices at home without any issue.       ... View more

That was fun. Thanks, @BrechtSchamp! I've included my own scavenger hunt below in the links. You'll know it when you find it.    BBC Radio 4 London May 25 Phishing DON’T PANIC What is the Answer to the Ultimate Question of Life, The Universe, and Everything? Looney Tunes Martian Deep Thought Neil Young Arthur Dent Douglas Adams ... View more

Yep, I think that's the part that we were all missing, that the APs had not yet been added to dashboard. With that in mind, the answer is no. You're not able to access the local status page via a wired connection. However, having the devices powered up without being added to the dashboard or any network connectivity, the MR should ideally broadcast a default SSID that will have Meraki in the name. It could be Meraki scanning, Meraki bad gateway, or Meraki setup. Are you able to see anything with Meraki in the name?  Once you connect to that you'll be able to connect to the local status page over wifi. When you are deploying these in an area with no DHCP, I would recommend powering on all of the APs while they are in the same room. Use the method that I mentioned, to assign the static IP to one or two. Then give the others some time. They might all just check into dashboard by becoming repeaters of the APs you configured manually. Often this method can be a bit difficult and frustrating, it is generally much easier to get them online with DHCP.  ... View more

I've updated the documentation to make it more clear. The local status page can be accessed by IP after enabling Remote device status pages on the Network-wide > General page. This allows you to connect to the local status page of the MS or MR even when not directly connected to the device. You'll then be able to browse to http://[device's LAN IP].   If the device has an IP but isn't checking in then this method will not work because this option is off by default. If the device has already checked in, then you can set a static IP directly from dashboard for that device without having to go to the local status page.  ... View more

Folding at Home just published a paper on how SARS-CoV-2 moves and folds. It's also pretty awesome that the community helped drive the Cisco Meraki team to be ranked in the top 300! ... View more

My suspicion is that the upstream modem is still caching the ARP entry for the spare MX. A packet capture on the primary MX internet interface should show the destination mac address of the 66.97.20.72 traffic. If that's different from the primary MX mac address then you might try rebooting the modem.    If you're not using a virtual IP then you might try that to see if it reduces the chances of this happening. But it really depends on where the failure is coming from. You might want to give Meraki Support a call for assistance in troubleshooting the specifics of your scenario.  ... View more

Wow! We are now in the top 500. As I post this, we are now ranked 497! Awesome folding everyone. ... View more

@Frankthetank, unfortunately, we don't have a good way to compare the points between the two platforms. While F@H is ramping up the number of work units that they have, sometimes the CPU ones aren't immediately available. Personally, I've found that pausing the folding and then resuming can force the Folding at Home client to reattempt the download.     @Jwiley78, looks good to me! Once you've completed some work units the points earned will update and will start to reflect towards "Team Cisco Meraki." ... View more

1) Yes, with 2 uplinks on each MX you'll have 4 tunnels. 2) On the traffic shaping page, you can disable active-active VPN. You'll need to set the uplink that you want the tunnel to be primary uplink.     ... View more